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In this iBHue 

Looking at software development tools and languages today, it's hard to imagine 

that just a few years ago FORTRAN was considered one of the primary languages 
of choice for most application development, and it took software engineers one 
or more days to write, compile, load, run, and debug a program that ended up 
using less than IK bytes of memory. Today, software engineers can go through 
the same process in less than an hour and produce a program that uses more 
than 1 M byte s of me m o rv^ Sta rtm g with the first five a rtic les, th e re a re n in e 
articles in this issue that describe tools and methodologies associated with soft- 
ware development. 

The SoftBench software development environment was released by HP in 1989. Since thattime over 80 
third-party software tools have been integrated with SoftBench, The success of SoftSench is based on 
the fact that it started life as an open, integrated CASE took That is, it not only provides a set of software 
tools, but it also provides a framework for integrating other tools into the development environment The 
first SoftBench article (page 6} describes the latest version of SoftBench, SoftBench 5,0, including some 
discussion about the objectives that have guided SoftBench development since its inception. 

Three of the new software tools integrated into SoftBench 5.0 described in this issue include: the C++ 
SoftBench class editor (page 12), which provides a graphical user interface for editing class constructs 
in a C++ program, the SoftBench static analysis database (page 16 |, which is a repository for generic 
program semantic knformation for languages such as C++, C, FORTRAN, Pascal, and Ada, and the C++ 
CodeAdvisor (page 19), which uses semantic information from the static database to detect high-level 
problems in C++ programs that are not typically found by the compiler. 

The final SoftBench article (page 22| describes a SoftBench solution to the problem of migrating from 
mainframe-based computing to a client/server architecture and dealing with a heterogeneous collection 
of machines with different system commands. The SoftBench solution is a daemon that allows developers 
to integrate heterogeneous computing systems into tightly-coupled software development environments 
with a consistent graphical user interface across all machines, 

Manufacturing organizations must always deal with determining how to balance on-hand part inventories 
and suppliers' response times. The paper on page 28 describes a project called supply chain, which 
focused on characterizing the various stochastic events influencing a manufacturing organization's 
shipment and inventory performance, A collection of statistical modeling assumptions, equations, and 
equation derivations are described that focus on minimizing on-hand inventory and optimizing supplier 
response time. 

The device shown in the picture on the cover is the neonatal version of a family of sensors (page 39) 
used for nonrnvasively monitoring the arterial oxygen saturation level in a patients blood (Sp02). In many 
medical application areas, such as anesthesia in a surgical procedure, measuring the oxygen level in 
blood has become as common as monitoring heart activity with an ECG. These sensors are based on 
pufse oximetry, which makes use of the fact that because of the change of arterial volume with each 
heartbeat, it is possible through measuring differences in light intensity to separate the arterial blood 
from other absorbing substances to determine blood oxygen levels. Besides neonatal sensors, there are 
also adult, pediatric, and ear clip sensors. 

The objective of a scanner is to digitize exactly what \s on the document being scanned. To do this per- 
fectly would require a detector with an infinite number of detectors and an optical system with the ability 
to resolve images to a high degree of sharpness. In the real world, scanners do not require perfect 
reproduction and the human eye does not have infinite resolving power However, as documents are 
enlarged and printers are able to print at higher resolutions, the image requirements on scanners are 
increased. The HP ScanJet 3c/4c color and monochrome scanner (page 54) has an improved optical 
system that addresses the optical parameters of image sharpness, signal-to-noise ratio, and dark volt- 
age, allowing customers to see the benefits of its 600-dpt resolution. 

Object-oriented languages, methodologies, and tools have been evolving for over 25 years. The concept 
of data hiding, in which data is accessed only through a well-defined interface and the data structure is 
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unkfiitvvn ta the accessing routine, formed the foundation of ttie object €oncept. As the next four articles 
show, tfiB language constructs and design paradigms growinf oyt of ttiis simple concept have had a 
profound impact on software design and development 

One of the benefits of obiect-oriemed technology is that objects can be updated without affecting any 
other part of the system. This capability is importani to system developers who must design their systems 
for change New technologies, customer demands, market forces, and other events all contend to make 
a system obsolete if it Is not able to evolve. The ORBIIte project (page 62) is a distributed communication 
framework based on object-oriented technology that supports piecewise evolution of components, inter- 
faces, commtinication protocols. APIs, and the mtegration of legacy systems. 

Software retise is anotfier benefit of object-oriented technology The article on page 73 describes a project 
in which Dbject'Oriented methods were employed to build a firmware platform for instruments using the 
concept of framework reuse. Framework reuse is a type of software reuse in which the interaction among 
the system components is reused in different trnplementations of the system. In addition to describing 
this firmware framework, the authors also discuss their experiences with using the Fusion process to 
develop their firmware framework. Fusion is a systematic software development method for object- 
oriented software development, 

A frequently mentioned problem in healthcare information management is the lack of compatibility among 
information systems. To help address this problem, the HP Medical Products Group established a project 
to create a high-level architecture and data interchange standard for healthcare information systems 
Ipage 86}. The architecture is based on the ability to decompose healthcare applications and systems 
into a collection of collaborative components, with each component able to implement the functions of a 
complete application or system of applications. Components are essentially bigger objects that represent 
a practical way to organize and package an object-oriented system. 

To help customers adopt object-orrented methods to solve their business problems, HP's Professional 
Services Organisation provides a suite of object-oriented education products. The article on page 9G 
describes the process used to assess cystomers* educational needs and the object-oriented curriculum 
available to satisfy those needs. 

C.L Leath 
Managing Editor 



The ptcture shows the neonatal version of a family of sensors (article on page 39) used for monitoring 
oxygen saturation levels in a patient's blood. 



What's Ahead 

It's a new yean and one of our 1997 goals at the HP Journal is to barter understand our readers' needs 
and interests. We'll take an important step toward this goal with the Journal's first reader survey in five 
years — look for it in your mailbox following the April issue, and please send it back! (If you don't, you 
won't be eligible to win the HP OfficeJet printer-fax copier we're giving away.) We'll incorporate your 
ideas and comments into a graphic redesign of the Journal that will debut in December 1997, and into 
other efforts to keep the Journal relevant and useful. To help us gel ready for the new design, as well as 
focus on these other projects, we've decided that we won't publish an issue in October 

The April issue will feature the design of the HP 54645D mixed-signal oscilloscope — a new category of 
instrument for testing combinations of digital and analog circuitry — and several related instruments. 
There will also be design articles on the HP 8720O vector network analyzer, the HP E4219A ATM network 
impairment emulator, the HP E4214A B-ISDN user-network interface signaling test software, the HP 
E5050A colloid dielectric probe, the SNMP+4 software for network management development, and five 
papers on IC design from the 1996 HP Design Technology Conference. 
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SoftBench 5.0: The Evolution of an 
Integrated Software Development 
Environment 



The vision and objectives of the original SoftBench product have enabled 
it to continue to be a leader in the integrated software development 
market. For example, since SoftBench ID, over 80 third-party software 
tools have been integrated with SoftBench. 

by Deborah A, Lienhart 



HP SoftBench iB an integrated software development envi- 
ronment designed lo facilitate rapid, interactive program 
constnietion, tesr^ aiul maintenance in a dLstributed comput- 
ing environment. The SoftBench product rontaiiis an inte- 
gration framework and a set oJ' softwaic development tools, 
as well as ttie ability to integrate tools from other soiirres. 

SoftBench was released in 1989 and presented in the June 
1990 t^P Joiunah^ At tl\at time, no one would have guessed 
the mat ket changes tl^at would occur during SoftBench's 
life. Fortunately^ the vision and objectives of the original 
product designers have allowed Sof^Benctt lo continue to be 
a leader m the integrated software develoiimeni market. 

This article presents the actions that have made SoftBench 
a standard in ( [le integrated softw^aie development market, 
the original SoftBench objectives that have stootl the test of 
time, and the new teclinologies that have been incorporated 
into SoftBench. Other aiticles in tliis issue will present niore 
infomiation about the new technologies in SoftBencli. 

Tlie different versions of SoftBench released shice its intro- 
duction in 1989 are shown in Fig, 1. 

MaMng SoftBench the Standard 

SoftBench defmed die open, integrated CASE (computer- 
aided softwate engineering) market. The fiist big challenge 
was to make SoftBench pervasive in the market. We used 



several approaches, including leading standards develop- 
ment, working wit It software tool providers, and hcensing 
the frmnework souice code. HP started mid supported CASE 
Commmiique, a standmds body that focused on defining the 
messages Lised for inteitool commmiication^ Tliis work was 
adopted as the basis of mtertool comniuni cation standards 
for soltware development tools by the ANSI X3H6 Committee. 

HP worked v^ith software tool providers, both tlirough CASE 
Communique and with uidependeni software vendor (ISV) 
programs^ to provide SoftBencti integrat ion for their tools, 
Tliere have been over SO third-paity software tools Integrated 
with SoftBench. and we contume to see interest from soft- 
ware tool vendors who v^f ant to integrate their tools with 
SoftBench. 

The source licensing program was interesting to many 
compmiies for a number of reasons. Some companies ported 
SoftBench to their haidwaie, added some tools, and sold it 
to their customei's. Several otlier companies have ported 
SoftBencli to their own hardv^'aie for use by I heir mtemal 
develojrnnent orgajtizations. One company, S.AIC (Science 
Applications International Corporation), comacts with cus- 
tomers to provide cross-development support for other, usu- 
ally non-UNIX, •- platforms. This is used mainly for legacy 
system support or to develop software for platforms that 
can't support a native apphcation deve kip merit environment. 
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Tills is the only part of the source licensing program that is 
still active. The articie on page 22 describes the acti\ities of 
the Science Applications International Corporation. 

Tine SoftBench broadcast message sender (BMS) framework 
was adopted by other HP products and some customers' 
products, in addition to its use in SoftBench. The biggest user 
of the BSIS ftamework is HP VT^ (\lsual User Environment). 
BMS provides the same open integration of desktop tools in 
HP M'E that it provides for software tools in SoftBench. For 
soflvvare developers* BMS also provides an integration of 
the desktop tools with software development tools. 

Original Objectives of SoftBench 

Tht* SoftBench fKunework continues to provide the founda- 
rion for SoftBendi and has stood die test of time. The follow- 
ing are th*:^ original objectives of the SoftBench architecture 
and the chati^e?? rhar have taken place, 

Support In teg rated Toolsets. Tliis goal dictated that the Soft- 
Bi'Hch luola should cooperate to provide a task-oriented 
eiiviromuent that lets users concentrate on wiiat they want to 
do, noi how to do it. SoftBench continues to provide a task- 
oriented environment by allowing tools to be stiirted from 
eacli other For example, in most SoftBench tools you can 
show the references for any symbol via the static anaiyzen 

Some users prefer a tool-focnsed environment, so SoftBench 
5.(1 ttas a new ToolBar to make it easier to see what tools are 
avaiJable in SoftBench (see Fig. 2)* 

Support interchangeable Tools, The concept of plug and play, 
wtiicii allows users to exchange a Soft Bench-supp tied tool 
with one of their preference, has guided SoftBench's ai'chi- 
reel tire and the development of standards in the CASE in- 
dusii-y. Text editors and configtt ration numagement systems 
are the most common tools that users customize. 

Support a Dtstribifted Computing Environinent Tliis go^il required 
lliat all t*>ol execution, data, mid display should bt* designed 
for a network envirfminent. Tliis objc^ciive was based on the 
scenario of a software development team using a grouji of 
workstations with var>'ing capabilides and shared projet t 
flies on a centrdl sen^er Providing distributed comjjutitig 
support in SoftBench htis not only allowed it to work well in 
this sceniuio. but alst> hiis provifled aflditional l>etu*rit in the 
ability to large! ctiiiipnlers and embetlded sysietns that vm\- 
not support an atJijlication development ernironnietit. The 
biggest SoftBench customers make use of this capability. 



Leverage Existing Tools. The reason for this objective was to 

protect customers' investments in software development 
tools by allowing these tools to fit into the SoftBench envi- 
ronment v^ithout modifying source code. This has v^orked 
well for lighiweigiit integrations, but most customers have 
decided that the increased v^ue of a deeper integration is 
worth adding a simple module to their ^Durce code. 

Support Software Oevelopment Teants. Originally SoftBench 
included integration with Ui S i Revision Conirol System) 
and sees (Source Code Control System ) configuration 
management tools and support for ac^cessing shared project 
files. In SoftBench 5.0» the SoftBench configuration ms^iage- 
meni product SfjfiBench CM was added. SojYBench CM is 
based on the history' management serv^er which has been 
used internally in HP for many years. SoftBench CM provides 
globiil source code management for software development 
teams whose members can be located anywiiere around the 
world. 

Support Multiple Work Styles. Software engineers do a number 
of ilifferenr uisks dimng the course of a project, including 
design, p rot t>ty ping, construction, defect fixing, and mainte^ 
nance. Each of tliese tasks requires a different emphasis of 
tlie software development tools. For example, construction 
makes extensive use of the editor and buikk^r defect fixing 
is centered in the debugger and niaintenitnce starts with 
the static analyzer Each of the tools is accessible froni the 
others, which allows a lask to have quick access to multiple 
tools or lo transirion between tasks. 

Support Other Life Cycle Tools. SoftBench supports the inte- 
gration uf t>!lier lool^? Hi at sui^pon the software life cycte. 
including (iorumentatinn, test, defect tracking, and design 
tt)€Ls. Most of the third-party tools integrated with SoftBencJi 
are in these categories. 

Build on Standards. SoftBench has always been built on stan- 
dards, such as flic l^NIX operating system, NFS and AliPA 
networking, the X Wimlfjw System, and the OSF/Motif 
appearance and hehavior In SoftBeitch 5.(1 we added inte- 
gration with the Comtnon Desktop Environment (CDE),'^ 
itu'luding CDE drag mid drnt>. 

New Tei'hnolti^y in SoftBench 

In the yeajs since the fn^i release of SoftBench, the breadth 
of tool support iuid functionality of the t<jols has Iricreased 
significantly. This section briefly describes some of these 
additions. 
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Fig. 2. A 'IVmlBar sfn^r^n. 
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Applying a Process Improvement Model to SoftBench 5,0 



Software organizations are under market pressure to reduce their cycle 
time and improve their development processes, The conventional ap- 
proach is to work on one< usually at the expense ol the other. For Soft- 
Bench 5.0 we decided to jump right in and attack both using a 12-month 
release cycle and CMM (Capability Maturity Modell level-2 processes. 
Using CMM-prescribed project management proce^ises, we reduced 
SoftBench 5.0's cycle time by 35%, improved product usability, and 
improved Durability to predict release dates. We also greatly improved 
the organization's ability to select, pfan. estimate, and track software 
projects. 

Reference t describes the software improvement project at our division 
that put in place the CMM process, Here we briefly summarize CMM and 
our approach to usir)g it for SoftBench .5.0. 
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Business Enviroitment 

SoftBench is an integrated application development environment for C. 
C++, and COBOL running on UNIX systems. It was first released in 19fia 
Since then the cycle time (that is. the time between one major release 
and the next) has varied from 18 to 24 months. In previous releases of 
SoftBench, the first part of the project was very unstructured, It typically 
involved market research, customer visits, prototyping, and design, but 
these activities were not well-fntegratel At some point we would de- 
cide what functionality should make the release and what functionafity 
would be rescheduled for the next release. A cross-functional team 
would be put into place to mariage and focus the release. This model 
provided little control ouer requirements or schedule. 

By the time we started SoftBench 5.0, we had taken important steps to 
impro\/e our product development process. First, we had a life cycle in 
place based do user-centered design. We had piloted elements of the 

user-centered design process with SoftBench 4,0, but Ihe life cycle had 
not been tested an a large-scale project Second, we had organized into 
cross-functional business teams, which helped speed alignment between 
marketing and R&D by putting a single manager in charge of both func- 
tions. And finally, we had just completed the SoftBench 4,0 test phase on 
schedule, proving that we had the ability to plan and schedule the latter 
phases of a project. 

To make matters more interesting, our new division manager, who had 
experience reducing cycle time, improving quality, and improving predict- 
ability using the Software Engineering Institute's Capability Maturity 
Model ISEI CMM), challenged us to get to CMM level 3 in 36 months, a 
process that normally takes two to three years just to go from level- 1 to 
Ievel-2 CMM compliance, 

Capability Maturity Model 

In 1987 the Software Engineering Institute [SE!i, based at Camegie- 
Mellon University, published the first version of the Capability Maturity 
Model (CMM). The initial intent of the CMM was to provide a process 
maturity framework that would help developers improve their software 
processes. 
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Fig, 1, Ttie five layers of the software Capabiliiy Maturity Model. As an organi- 
zation adopts the practices specified in the n^odel, its software processes should 
see greater productivity sod quality, 

CMM describes five levels of software process matunty (Fig.1). At the 
initial process tev8f \\Bvel 1) an organization operates without consistent 
application of formal procedures or project plans. When things get tight, 
the level- 1 organization always reverts to coding and testing At level 2, 
the repeatdble l^vel, conrrols are established over the way an organiza- 
tion establishes its plans and commitments. Requirements, plans, and 



Static Database. In SoftBench 3.0 a new object-oriented static 
database was placed imder SoftBench s static analy;?er. 
Earlier \Trsions of the static analyser C'oidd only analyze 
30,000 to 4(),()t)0 Ujies of source code before reaching ca|>acity 
limitations. The new static database does not liave capacity 



Uniitations ivnd perfonnance is acceptable for up to about 
one million lines of source code. 

In addition to the capacity aiid performance improvements, 
the object model of the new static database makes it n\ore 
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pfocedures are documefrted, at feast at the proj^t level, wfiich mearis 
the process could be repeated in the future as long as the type of soft- 
w.'are bang develops dc^sn't change too much. At the defmedtevet 
llevel 3), the organnatton has documented both its management and 
enginsenng processes This allows the organization to begin to improve 
^ses over time Level 4. The managed fevei is where an organh 
in quantitatively measure tis development and managemeni 
processes. Finally, al level 5, the o^miiing lev^. the development 
process o|^ra!es smoothly, and continuous impfovement occurs on the 
defined processes established in the previous levels 

For each level of process maturily, CMM describes the relat^l key 
practices that characterize that level of process maturity 

Each key process area is defined by a set of one or more goals, as well 
as the specific practices which, if followed, help achieve the goals, The 
key process areas and practices are intended to describe what needs to 
be done to efficiently and predictably develop and maintain software 
The CMM does not attempt to specify how software should be developed 
and managed, leaving that interpretstton to each organization, based on 
its culture and experience. 

Project Infrastructure 

We chose to move to level 3 by adopting CMM level-2 processes im- 
mediately on all new projects, SoftBench 5,0 was the first and largest 
project to use the new processes and our project infrastriiclure was 
designed to support this approach. The key components of our project 
infrastructure were a life cycle based on user-centered design, a Web 
server connected to our conflguraiion management system, and a pro- 
cess consultant and a project lead. 

The life cycle had been under development for about a year and we had 
already used it successfully on some parts of the previous SoftBench 
release The life cycle uses a simple waterfall model augmented with 
CMM level-2 practices and user-centered design, 

CMM lBvel-2 practices ensure thai requirements, plans, and schedules 
are documented, revievwed. and approved by management Moreover. 
levehZ practices ensure that as requirements or designs change, the 
associated plans and schedules are revssited to make sure they are still 
valid. 

User-centered design is based on the premise that a product's success 
depends on how well the product addresses the needs of the people who 

use It. User-centered dessgn does this by involving potential users in key 
development activities, such as profiling user charactenstics, character tz- 
ing goals and tasks, and validating potential product features and design 
altematives 

All of our project documents were checked into SoftBench CM. Soft- 
Bench's configuration management system A Web home page was 
created for the SoftBench project, allowing us to retrieve documents 
from SoftBench CM and display them with a Web browser, such as 
Mosaic or Netscape. The home page sncluded a section for each of the 
SoftBench teams |to point to customer survey data, requirements, and 
designs^ and sections for product documents, project planning documents, 
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Fig, Z The network confFguration that supported the project infrastructure 
for the devBlapmeoi of SoftBench SM. 

project schedules, and life cycle guidance. WeVe always checked project 
documents into our configuration managemeni system, but the addition 

of the Web browser really improved the visibility and access to these 
documents. Rg 2 shows our Weh intranet structure. 

The third key component of our project infrastructure was the process 
consultant and project lead, We had a full-nme project ie^d and a full-time 
process consultant focused on the CMM practices, both as part of the 
formal management team We also had a half-time usercentefed design 
consultant hom our hurrran factors organization to help us apply the user- 
centered design techniques, Having these two individuals share account- 
ability for both process and project management proved to be a major 
success factor. 
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flexit)le for mUlmg language tyjips and qupries. Tlie Soft- 
Beiich st<it ir anaJysis tlatiif>aKt^ ts ciescribecl in tJu' anU'le on 
page 1(3. 

Rule Engine, In Soff,Bt>nch 5,0 a rule engine was implement c^d 
as pan *)f the Sot't Bench t'tHleArlvisorimKluct. A nilv is im 
plemtniii'd as a C++ chy^s, whU'li ami iivcvns mkyiin^lUm in 



tlic^ static database ant! any mhiT infomiafion available to it, 
T\w i-uJes are mn by the mie engine, wliich is integraled inlcj 
the StjftBen^ii program bntlcler/^ 

A set of C++ coding niles is included in SoftBench 5.0. These 
nries ehet^k for fliingenitis c*odijig pra<1iees, whic!i are !h(* 
ones tlial woukl create nieintjry leaks or have untuiiii ipated 
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skie effects. Information and examples needed to create 
rules are mcluded in the SoftBeruli software developer's kit. 

The SoftBench CodeAdvisor is described on page 19, 

New Languages. The first release of SoftBench supported the 
C language. C++ SofTBench was added m 1991. C++ enhance- 
ments were made to tfie SoftBench fools and a C++'Specific 
tool, the C++ Developer, was added. Tlie C++ Developer 
was designed to be a training tool. It had a graphic display 
of the class inheritance hierarchy, iind the luser could add or 
delete classes and mheritance relationships from the graph. 
It could also automaticaily Cix common coding problems 
before they were caught by ihe compiler hi SoftBench 5.0, 
the C++ Developer was replacet! by the graphic editing func- 
tionality hi tlie SoftBench static anjUyzcr's class graph. 

COBOL SoftBench'^ was added to the product family m 1994, 
It provides encapsulatioris of most of the Mic^roFocus COBOL 
tools. The SoftBench developmen! environment makes it 
eai^ier for usera to transition to tJie UNIX operating system 
from mainframe development emironments. COBOL Soft- 
Bench provides a conmion development en%ironment for C, 
C++ , and COBOL. This is especially helpfyj when debugging 
an application that Ls a combmation of COBOL and C or 
C++. Micro Focus' .Animator and SoftBencli program debug- 
ger ]:»ass <'0ntrol of the application between thentselves as 
the application moves between modules implemented in 
chfferent languages. 

SoftBench CM. The SoftBench configm-ation Jitanagement 
l^rodiK 1 was introduced in 1905. It is based on the history 
managt^ment server, an uitemal too! that has been used for 
most of HP's software develoi>ment. 

SoftBench CM is a scalable configuration management tool 
that offers efficient code management capabilities for team 

• The COBCl SaftBench family is based on HP MF CDBOt. HP's impJemernation of MicroFocus 
COBOL wfiich is based on fechF>ologv from Mic/oFocus, Ud 



members arul work groups, including those wIkj are geo- 
graphically dispersed in dJstajit locations. Based on a client/ 
server archiiecture that is designed to allow access to multi- 
ple local or remote servei's, SolYBencrh CM is easily accessetl 
from any of the SoftBench tools (see Fig. 3). 

SoftBench CM can manage different versions of any type of 
file. Many of our customers use SoftBench CM to version 
nonsoftware files^ including project docimients and bitmaps. 
A PC user interface has been developed thai allows users in 
mixed LTNIX and PC enwonments to create versions of 
their PC-based files along with their UN IX -based files. 

Graph Views. In the original version of SoftBench there were 
only textiiiil interfaces. In SoftBench 3.0, graphicaJ inter- 
faces were added to many of the SoftBench tools j htctuding 
the dependency graph browser in the program builder, tJie 
static graph browser in the static analj^^er, and the data 
giatih browser in the program debiiggei: 

In SoftBench 4.0 the imderlying graph libraiy was replaced 
by ^m implementation based on a tliird-party graphics library 
called ILOG Views. This implementation is nmch faster and 
will hmidle a lot more nodes than the old implenuniiaiion. 
The static giaph browser was replaced witl^ three special- 
ized graphs for files, fimrtions, and classes. 

In SoftBench 5,0^ graphical editing capability was added to 
the SoftBench static ai^alyzer's chiss graph and its ntune wtis 
changed to the class editor. The article on page 12 describes 
the C++ SoftBench class editor 

More Platforms. SoftBench originally supported IIP 9000 
Series 300 worksialions tmd HP 9000 Series 800 file servers. 
Support was added for the IIP 9000 Series 4(K) and Series 
700 workstations and HP 9000 Series 800 sei-vers with X 
tenninids. In 1991 SoftBeru^h was released for SunOS and in 
1993 su]>port was added for Sun's Solaris operating system. 




Fig, 8, A SoftBench CM screen. 
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DDE Debugger In SoftBench 4.0, the underljing debugger for 
^k>ftih?nch's progmm debugger was changed fn:jni xdb to the 
HP Distributed Debugging Environment (DDE) from HPs 
Massachusetts I^angu^e Laborator>: HP DDEs architecture 
isolates most of ilie debugger from spedilc infomiation 
about the target operating system, computer language, user 
mterfare. and debug foruiat. The SoftBench team Imple- 
mented the SoftBench proj^ram debugger user interface on 
top of HP DDE and ported the whole thing to the Solaris 
operating s^'Btem. This Is the only development en\irorinient 
that supports both the HP-irX' and Solaris operating systems 
with a common debugger, using the compilers supplied by 
the sJ^stem vendors. 

Toot Bar SoftBench is a powerful development environment 
and as the user base has expanded we've placed more 
emphasis on making it easier to learn and use. Many times 
users requested toob that were already in SoftBench so we 
added an iconic TooiBar to make the available ttwls \isible. 
Tlie Tool Bar supports drag and drop integration with HP 
VUEandCDK 

Conclu^sion 

^Tien SoftBench w as first emisioned, l"NLX software devel- 
opment tools consisted of compilers antJ debuggers, and 
real softwiire engineers didn't use windows. SoftBench w^as 
the firs! integrated application de\ elopmem einironment 
running on the UNIX operating system. 

There* w^asn't mucli to work with then, just RFA (remote file 
access) and TCTYIP networking imd the begimungs of the 
X Window System. Motif came along diimig Uie development 



of the first release of SoftBench and XFS came along later. 
^Tien HP's Software Engineering Systems Di\ision ( SESD) 
developed the BMS (broadcast message serv^er) for inter- 
process communication and it was included in HP YUE, it 
changed the capabiUt>' of desktops for e\'er>'one. 

Ch er the years SEISD has developed new technology for the 
challenges brought on by the C+^^ language and lar;ger appli- 
cations. We also adde<i a lot of ^^pMcs as the technolog^^ 
l>eeame available and workstation perfomtance increased. 

In the future, SoftBench will face new challenges associated 
with developing distributed applications that nin in hetero- 
geneotLS emiroranents. We can look to the original objecti\es 
and architecture for a path that has stood the test of time. 
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The C++ SoftBench Class Editor 



The C++ SoftBench class edftor adds automatic code generation 
capabilities to the class graph of the SoftBench static analyzer. Novice 
Ch- programmers can concentrate on their software designs and have the 
computer handle C++ s esoteric syntax. Experienced C++ programmers 
benefit from smart batch editing functionality and by having the computer 
quickly generate the program skeleton. 

by Julie B. Wilson 



T3ie C++ SoftBench class editor allows the ])rogtaTmiier to 
edit the class constructs in a C++ program using the Soft- 
Bench static analyzer's graphictil interface. Using liie class 
editor, tiie progranuner can create and modify class hierai- 
clues and edit class components^ 

Since the class editor is part of the static aruilyzei; let's look 
first at the fimctionaht.y provided by tJie static analyzer. The 
static analyzer helps tlie progranmier better understand the 
code. Through static queries, the progianuner can understand 
a program s si.nicture, assess the impact; of rlianges, and 
ch^tnge the architecture of the cfKJe when necessaty. Thc^ 
static anal:y'zer presents a wide variety of hifomiation alHait 
tlie code, including infomiafion about variables, classes, 
functions, and files. Through queries, the programmer can 
aJiswer questions sucli as, "What fimdions and classes call 
this finuiion?" or "Wial code accesses ajiy element of this 
class?" The results of tfie queries can be displayed either 
tcxtnally or graphically. From eitht^r display, a simple double 



click lakes the progiamnier threcdy to the source code that 
supports the displayed information. 

To use the static analyzer, the programmer must first gener- 
ate static information about the aptilication. Tlie default 
compile nuHk^ in the SoftBencii tirograrn builder generates 
the static database (the Static.sadh iile). VVi^en the programmer 
builds the application, the compiler places tlie static data- 
base in the directory in vidiich the programmer cornpded the 
code. All static queries rely on the information stored in this 
databjise. 

Benerrts of the Class Editor 

SoftBencli 5.0 adds editing capabilities to the class graph 
t>rovided by the static ^iiialj''zer. With the class etlitor, a no\ice 
C++ progranuner ca)i concentrate on softwai'e design, class 
hierarctiy, data members, and member fimctions, not on 
C++ syntax. Mter each edit request, the class editor atdo- 
maticahy generates the specified C++ code with coirect 
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Fig. 3, If the programmer removes a class in ihe middlf of an in- 
hc*ncaricc» «;micnirc^, tho class editor makes the necessai>' edits t^ 
maintaifi the renialning relationships, (.a) Before the B class is 
dejeteci. (b) Aiter the B cia^ is deleted. 

The programmer can expand and contract class nodes to 
show the dala members and member hmctions in the node. 

Fig. 2 sliows the same prograni ihat was repn^senieii h\ Fig. 1, 
but tliis time the visual disi>la> has been changed by filtering 
out all the classes from libnu^^ header files. Additionally, 
two of the nodes have been expanded to show the member 
functions. 



syntax. Tlie class editor aly<.i cht^cks the work iuid tloesji'l let 
tlie programn^er make tyi>icid beginner's mistakes like using 
the same class name twice. 

Exfwrt C++ programmers also bcnefil from the class editor. 
h^ addition to the progrjrun visu^dization cai^iitjilities of die 
graph, experts cati fptiekly generate a program skeleton or 
make changes to an existing ijrogratn's stmcture. Even more 
useful ai-e the powerful, static-assisted edits that the class 
editor supports. Usijig Uie class editor, the prf^^raiiiniHr 
ran change the niune of a class or {lass nieiuber and all tfie 
appropriate changes are made in tJie sinirre code. These 
changes can span many files. Because of the underlying static 
database, if Ihe programmer c*hanges the name of a member' 
function x. the class (*cjifor knows exactly which instances of 
X are n*l(:n'ant anti which instances aie not. 

Controlling Complexity 

Fig. 1 shows an cxauit^le of a C++ program with the classes 
;m<l inheritaitce relatitJDsliips (itHplayed. The class editor 
provides ihe alnlity to disjjlay juajiy relationsltips in ackiit ton 
to inheritance, such as friends, containment, anci accesses 
by members of other clas.ses. 

hsLTge C++ applic'a lions tend to ha ye many classes ;uid many 
relationships am(7ng the classes. Tlie class editor provides 
several featirres to help control the complexity of what is 
displayed; 

• Fillers make it possible to display onJy the type of data in 
which tile progianuner is interested. For example, if tiie 
prograuuTier only wants to see inlieritance relationshijjs, all 
Citlier types of relationships can be iiltered so they are not 
display t^d on the gi^aph. 

• The progrannuer can redttce the camplexity of tlte graph by 
hiding nudes tJiat are ntvt currently of interest. 

• The prograjumer can adrl nodes to the graph directly by 
name or indirectly by querying about relationships with 
nodes already displayed on the ^aph. 



Changing the Class Hierarchy 

Like any editx)r, the class editor allow^s die programmer to 
adfl. modify, and delete edited objects. For example, tiie 
prograimner can add classes, iitlieritance relationslups, 
memher ftmctions, and tlata members. (Jnce these C++ 
stnictures exist, they can t>e modified or deleted. For exam- 
ple, the progrmnmer can chimgc an inheritance reJationsliip 
from public to private or delete the relationship entirely. 

If the }>rogrammer finds it necessary to restnuture relation- 
ships by rcmoiing a class in th(» middle of an inheritant^e 
structure, the class editor makes the necessiuy edits to 
maintain the remaining relationships, as shown in Fig. ■! In 
this example, A is the base class of H* and B is the base class 
of C and I), rjecause the ]>rograiti archiicfiure has lieen 
changedj the progranuneT no longer wanis the B class. When 
B is deleted, the class etlilor automatically maintains the 
inheritajice reiationship,s so that A becomes the base class 
ofCandlX 

Recovering from Editing Mistakes 

The class editor remembers edit requests so Uiat the pro- 
grammer can ur^do them in reverse order For example, if 
tJie J programmer adds a base class relationshiti mui then 
reconsiders, the Undo menu c*ommand on the Edit menu reads 
Undo Adding Jnheriiance. 
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Fig. 4, \n SoftBeneh. compilations that produee static infon nation 
are iritpleniented uith two parallel, independent tauLd processes. 
The .standard criinpUer pr^xluces the error log and itlijt^rt ( o) files. 
Tlie sbparse eotnniaiid produces the statk: dataiMi.se^ Static. sadb. 
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Fig. 5. .Sequence of riornpletittg a cJass editor edit ® Edit tli.spiai'ed 
on graph. ® Files iipdatftj, ® F[LE-MODIF!ED messajie results in re- 
display of file ill editor. ® A ftimplle witli -nocode -y rjprjnns updates 
the dam base. 

Keeping tiie Static Database U[j-to-Date 

In So ft Bt'i It'll . r o ni j > i 1 a I i oi ts tl la t pr odi i ( :e fit.at i c i r i I'orm ation 
are imple nie at e 1 1 vv j 1 1 1 t wo p tir^iJ le I , in r I e| >e t ) il e ti 1 l>iii Id pro- 
cesses (see Fig. 4). The stantlaid cuniptlei; a cfront-btised 
compiler, produces U^e error log and object (,o} files. The 
-V compiler ojition ttiggers the sbparse rotuttiund, which is 
a subset oi HP's ANSI C-S-+ compiler. The sbparse conmiand 
produces tlie static database, Static.sadb. 

The -nacode conti>iler ofition tells SoIlBcMteh not lo run tJie 
cfront-l)ased compiler. Since eveiytJiing thai tlie static analyzer 
knows depends on the imderlying static database, each class 
editor ec!it reqnest needs to update the static database. Ulien 
the progranuner re<jiiesl.s an edit in the class editor, the class 
editor executes a coiu]iile v^ idi the -nocode -y compiler op- 
tions, updating the static database without cheekhig syntax 
and without producing o files. 

Using the Class Editor witli a SoftBeneh Text Editor 

Tlie cltiss ecUtor saves after ever>^ logical edit. For exaniple, 
if the programmer creates a new class, the imderl.yuig source 
code file clian^Jfes when the prog rail uuer makes tJie request, 
and the < las.s editor sends a FILE MODIFIED message to let other 
tools know that liie Hie changed. 

If the prograimner has a SoftBeneh text editor open wliile 
WTjrking in the chiss editor, the FILE-MOD] RED message causes 
the text editor to refresh the disfjiay of the file and the pro- 
grammer can see the immediate propagiition of tlie new^ 
source code. 

Fig. ^ shows the sequence of events that occurs w'hen the 
prograintnet makes an edit usitig the class editor: 

J , The class editor perlbmis pre-edit checks to make sure 
that the edil makes sense. Assuming that the request passes 
the pre-edit checks, the edit is displayed on the giaph, 

2, The class editor updates the underlying files that are im- 
pacted by tlie request. 

S. The class editor sends a FILE-MDDiRED message to notify 
other tools tliat tlie edit took place. 

4. The class editor executes a comjule with -nacode -y 
options, which updates the Static sad b file. 

If the prograiimier chooses to make edits in the text editor, 
tlie sequence of events is slightly different (see Fig. 6 ): 

L When the progranuner saves t he file, the tex1 editor up- 
dates the underlying fde anti .sentis a FILE-MOO IFIED message. 



2. The class editor receives the FILE-MODIFIED message and 
jxists an iid'otniatirm dialog box stating UndD disabled due to 
external edit. 'Hie class editor then erases the tnulo slack, 
since the external edits may have made the undo actions 
invalid, 

3- The c:ode changes in the text editor are not immediately 
propagated back into the class editor. The programmer must 
mitiate die action I bat updates the static database ajid the 
grapliical display. Tf> update the static datahasejhe pro- 
grammer chooses the FlJe: Anslyze Fie Set menu comniatKl on 
the main static analyzer window. This memi commanfi exe- 
cutes a -nocode -y compile. 

4. After updating the static database, the programmer needs 
to select the Update Graph button in the class editor to display 
the code cluinges made in the text editor. 

Working with Con:5g:uratton JV!anai?enieiit 

Edits in the cUlss editor havt^ the potential to change many 
files. For ex;unj)le, if the [:)rogrammer changes the name of 
a class, several files may net^d to change. With the powerful^ 
static-assisted editing, the progrtmimer may not be aware of 
which files are changing, C/otisetiuently, the (programmer 
can attempt to initiate edits on Hies that, do not liave write 
perniission. 

^^^len the class editor runs mto a problem with file j>ennis- 

sions, it posts a tliiijt)g box giving the programmer three 

choices: 

Let tlie class editor check out I he necessaiy files. ThLs option 

is only valid if the tiles ate under configuration management 

and available for checkout. The class etlitor completes the 

checkout process by semUng a VERSION-CHECK-OUT message. 

Resolve the problem nianuaUy, then select Retry on the dialog 

box. 

Cancel the edit. 

Fixing Compile Errors 

The class ettitor does not inttodtice compile errors when it 
creates cotle. tiowever. it is possible for tiie progrtumiier to 
introduce compile errors. For example, the programmer 
might reference a hniction before creating it, make a typing 
error on a varialjle name or^ ijpe when adduig a data member, 
or make a syntax error in the body of a member ftjnclion. 
Neither the class editor nor sbparse catclies syntax errors of 
tiiis tyi,>e. 
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Fi|?, 6, Sequence of uptlating the class editor after an external edit. 
(D Files updated. ® FILE-MODIFIED message disables the uitdu slack. 

® An Analyse File Set itieuu Loniin:uid triggers a compile that updates 
the databtise. ® An Update Grapti comniaiid displays tliti externaJ edits 
on the graph. 
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At first this model may appear surprising, but it actually 
works to the user's ad%^aiita^e. When the progmmttier uses 
a traditional text editor^ code is not always conix^ liable as tt 
is being develop eti. The prograiumer may friH^iuentiy create 
code objects oat of order, mentally keeping track of what 
still needs Uj be done. The ctass editor functions in much the 
same way. If it detected every compilation problem, work 
would soon grind to a halt Instead, the programmer can 
complete the code development tasks and let Uie compiler 
catch the syntax errors later. 

Preserving AVliite Space and Comments when Editing 

The algorithm for completing aii edit allows the class editor 
to preserve spaces, lafjs, and comments in Ihe code being 
edited. When the programmer specifies an edit, the static 
database provides the class editor with the specific positions 
in the source (hat need to be edited. The soiu^ce code is then 
searched for 'landmarks" to ensure tliat the riglit part of the 
code is being changetl. C )ttly minimal additions, substitutions, 
and deletions are done to tlie source file. For example, when 
a class is renamed, each reference is replaced by the new 
name, leaving any user-added comments oi^ white space 
intact. 

Wlreri more complicated things are changed, like the retimi 
type of a function, several c<msecutive tokens may be re- 
placed with new text. In this case, any conunents that are 
betw^een the old tokens for that type are lost. 



experience a race condition- If the database is not yet up-to- 
date w^hen liie class editor attempts to complete its pre-edit 
checks for the next edit, the progranmier will get an error 
message. For example, if the programmer creates a class, 
then attempts to add a member to the class before the 
create class edit is complete, the error Class <class name> not 
f aund will be issued. To resolve this error, the programmer 
should w^ait a moment ajid try again. 

Conclusion 

Tlie static analy7.er aiid Uie class editor together offer tJie 
C++ progiammer a powerful program visualization and edit- 
mg tool. Tlie editing capabihties of the chtss e<litor facilitate 
program construction and editing. The code generation 
capabilities of the class editor facilitate [program correctness 
ai^d cojisistency. Code generated by Uie class editor is syii- 
tactically coixect and consistently formatted. When the pro- 
grammer makes a misliike using the the class editor oi^e or 
more edits can easily be backed out using tlte Edit: Undo menu 
command. 

The filtering capabilities of the static analyzer allow the pro- 
grammer to control the complexity of what is displayed and 
to conceal irrelevant details easily. The visualization capabil- 
ities of tlie static analyzer aid program comprehension. The 
programmer can choose to investigate mjuiy iyi:)es of rela- 
tionships in the code, and can easily access the underlying 
source code wheii more detail is needed. 



lYouble^hooting 

The error Unable to update the database is fairly common. It tends 
to occur with existing code that hLis compile erroi^, and it 
usually indicates a missing include file. To avoid this error, 
the prograttimer should make siue tliat existing code com- 
piles without errors before starting to use the class editor. 

Much more larelyi timing problems are encountered. When 
the progranuuer requests an edit, the first step is to make 
the edit visible on die graph, and the last, step is to update 
the datal>ase (see pre\iDus discussion under 'TJsing the Class 
Editor with a SoftBench Text. Editor"). Because the class 
editor allow^s the programmer to begin the next edit as soon 
as the previous edit is \isible on the graphs it is possible to 
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The SoftBench Static Analysis 
Database 



The static analysis database supports the SoftBench static analyzer and 
the C-K, C, FORTRAN, Pascal, and Ada programming languages. The 
underlying data is isolated by a compiler interface and a tool interface. 

by Robert C. Bethke 



The Soft Bench statix- analysis daUbiise, Static.sadh, is a repos- 
itory for generic iirograni semantic iiifonnalion. Within Soft- 
Bench the database supports the static analyzer ah>ng with 
grapliical editing aiuJ nile-basefl program cheeking. The data 
niodei is relatively general and currently supports 0++^ C, 
FORTRAN, Pascal, aiid Ada, 

Tiie database also serves as a product and can be customized 
by tlie user. Its compiler interface and tool mtcrface aie 
docmnented and allow the uitegi-ation of other languages 
and compilers and the use of custom analysis tools. 

The Data Model 

The underlying data is a set of persistent C++ objects. These 
objects serve to model the semantics of the program. The 
underlying persj .stent objects aie isolaled by the compiler 
interface and ttu^ tool interface. The isolation ivas importmit 
impUcations for allowing a ^^ariety of compiler integrations 
mid provides flexibility in changing the underJ>1ng data man- 
agement without affecting either the compilei-s or the tools. 

Many of the persistent objects are language-generic (lan- 
guage-insensitive) and are intended to model all similar con- 
structs. For axample, a Struct object is used to model C st.nic- 
tures and Pascal records, A FLnction object is used to model 
fimctions ainl procedures in all languages. In some cases, it 
is nccessaiy to have language-specific objects because the 
semantics are too specific to apply to other languages. 
Examples of lajiguage-siJecific objects aie C-h+ Class ol>jects 
and Ada Module objects. 

Each persistent object is assigned a miique object identiBer 
known as a handle. Given m\ object*s handle, it is possible to 
query^ i he object by means of methods for relevant informa- 
tion such as Rs name, list of references, cind so on. AE asso- 
ciations among the persistent objects aie maintained by these 
handles. For example, the tissociadon from a VarcahJe object 
to its typedef object is niaintained by tlie Variable's having the 
liandle of its typedef as an attrihuie. One-to-many ass<x*iations 
are maintaiiied as a set of hanrlles. For example, a Fife object 
will have a set of handles to associate aU other source files 
mcluded by it. 

To illustrate associations, consider the following C code: 

typedef struct S (iiit x; int y?} SType; 
Stype var; 



The assoriations among the semantic objects in this code 
fragment aie shown in Fig, L 

Container objects are used to model scoping and binding 
and to organize the semantic objects for efficient uptlating 
aiid na%dgation. Each container has a set of lumdles for till 
objects contained in it and each object contained has the 
handle of Itis container. Examples of container objet ts are 
FUeSj Functions, imd Classes. A File contains the program con- 
structs defined in that source file, a Functmn contains it3 
parameters and l^ltjcks, and a Class contiiiiLs its rnembens. 
For example, Fig, 2 shows the object contaiiunent for the 
following C++ class definition: 

Class ci& { 
public: 

clfl (int x) {nieni=x; } 
private ; 

int mem I 
}! 

The Semantic Objects 

The foll(jwing is a paitial hst of the semantic objects stored 
in tJie datal>ase. 

SymhotTable. The global Sym bo liable is a container that serves 
as the tool of navigation in the database. It-S eti tries arc aU 
globally scoped semantic objects and Files in t!ie tiatabase- 
There is only one global SymbolTable per database. 

File. A File is a container that contains all seinaiitic objects 
tliat are defined in a specific somce file. Attributes of a Rle 



Has Type 






Has Type 




Has Tvpe 




Pig* I* Associations among semantic objects for the C code example 
givpu in the text.. 
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Fig. 2. nbjpf-t containment forari exanipl** ^^^ *'-hkH^^ (^p^nmhm 

are its name, a language kiiitl, iiiul a set of hictude and 
inrhuled bi/ associatiuns with tjther Files. 

Module. A Module b a container that contains all semantic 
ubjects that are ctefinetf within an Ada mcKiule, A Module 
miLst be contained within a File or within another MaduEe. 
Attribiites of a Module are its najiie atid a set of imported 
associations with other Modules. 

RefList. A f^efLisi is an array of references that are associated 
Willi n^imed objects in the database. Atinbules of a RefList 
are the corresponding referent (the File in which tiie refer- 
ences originate) anti the titimber of references in the ILsl 

Macro. A Macro is a language-generic object for representing 
a preprocessor or language macro. Attributes of a Macro are 
its name ar\d a set of Ref Lists, 

Irientlfier An Identifier is a language-generic object for repre- 
senting a lumied s>inbol ITiis object is mostly used by 
weaker (sciin-based ) parsers dial <!(> m>T inteiul lo distin- 
guish certain categories of objects. Attni>utes of an Identifier 
are its name and a set of Ref Lists. 

Label. A Label is a language-generic object for representing 
statement labels. Atlrihnres of a Label are Its name, an 
enclosing Block or Module, and a set (if RefLists» 

Variable. A Variable is a language-generic object for represenling 
vi^riabl(^s, Attributes of a Variable are its naJiie and type, an 
enclosing Block or File, luul a set of Ref Lists. 

Function. A Function is a langnage-genenc object, for represent- 
ing finunions and procedures. Attributes of a Function are its 
name, a retuni lyijc, a set of Parameters, an outer Block, a con- 
tainer (the enclosing Ffle, Module, or Block), and a set of RefLists. 

Parameter. A Parameter is a language-generic object for repre- 
senting function paraineteiii. Attribiites of a Parameter are hs 
name and ijpe, an enclosirig function, and a set t)f RefLists. 

Block. A Block Ls a container for representing a function block. 
Attributes of a Block are its begin and end line numbers, tJie 
RIe in wiiich k is contained, and an enclosing Block or Function. 

Typed^l. A Typedef is a huiguage-genenc object for representing 
named program types. Attributes of a Typedef are its natnep 
the type it denotes, an enclosing Rle or Block, and a .set of 
RefLists. 



Tag, A Tag is a language-generic object for representing aggre- 
gate (Enum, Struct Class, and ClassTemplate } t>pe names. Attrib- 
utes of a Tag are its name, the aggregate it denotes, an en- 
closing Rle or Block, and a set of RefU^s. 

Enum, An Enum is a language^eneric object for representuig 
enumerated tjpes. Attributes of an Enum are its correspond- 
ing Tag and a set of Enum Members. RefLists lo the enumeration 
are on the corresponding Tag. 

EnumMember- An Enum Mem bar is a language-generic object for 
represemiJig enimieration constants, Atlrtbutes of an Enum- 
Member are its name, an enclosing Enym, m\ ordinal value, and 
a set of RefLists. 

Struct A Struct is a langnage-generic object for representing 

progrant structures, records, and unions. Attributes of a 
Struct are its corresponding Tag and a set of Data Members. 
RefLists to tJie Struct are on Uie corresponding Tag, 

DataMember. A DataMemher is a language-generic object for rep- 
resenting fields of a structure, imion, class, or record. Attri- 
butes of a DataMember are its nanie and type, an enclosing 
Stnjci or Class, and a set of RefLists, 

Class. A Class is a C++-speciftc object for representing C++ 
classes. Attributes of a Class are its corresponding Tag, a set 
of Data Members, a set of Function Members, a set of base and 
derived Classes, a set of friend Classes and frieml Functions, a 
set of iiested Classes within, and the ClassTemplate of whicli it 
is an instance. RefLists to the Class are on the corresponding 
Tag. 

Function Member. A FunclionMemher is a C ++-speciflc object for 
representing C++ class member functions, Attrihutes of a 
FunctionMember are its name, a retuni type, a set of Parameters, 
an enclosing Class, the File in wluch it is defmed, an outer 
Blocks and a set of RefLists. 

CiassTemplate. A ClassTemplate is a 0++ -specific object for rep- 
resenting class templates. Attributes of a ClassTemplate me its 
corresponding Tag, a set of DataMembers, a set of FunctionM em- 
bers, a set of Functionlempiate menibei's, a set of TemplateArgu- 
ments. a set of base and derived Classes £md ClassTempiates, a 
set of friends, and a set of Class instances. RefLists to ttie Class- 
Template an^ on tlie (corresponding Tag. 

FuncttonTemplate, A FunciionTemplate is a C++-speciric object for 
representing fnnction templates. Attributes of a FunctionTam* 
plate are its name, a set of TemplateArgumertts, and a set of Func- 
tion or FunctionM ember instmices. 

The Compiler Interface 

From the eoiuinler perspecrive the database can be Uioughl 
of as a persistent symbol talvie for a set of source files such 
as a librajy or an application, Tiie conipiJer sees tiie contents 
of oitly one compilation unit and emits information accord- 
ingly, l>ut the database creates only objects that are not yet 
in the dataljiise. The database creates and merges Jill the 
progfiun objects as the source files are compiled. 

C'Ompilation may rcsiill in objects being removed. Persistent 
objects aie removed when they are old or arc contained in 
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objec^ts ihat lu'e old. For example, when a file has been niod- 
ified and is being recompiled, the File is okl ajid its contents 
are renio\^d from the database. T\\e conipiJation will proceed 
and instantiate the appropriate* new objects contained in the 
File. 

The database is incremental to the file tevel If one source 
file in an application or library is changed, the conipilatioji 
will result in ti^e removal and rep o pupation ot objects in ttiat 
RIe. After the compilation the database is again corvsistent 
and available for queries firom a reader. 

The compiler interface is procedural in style and is intended 
to be easily added to most comt>ilers. The interface is stmr- 
tured aroimd the creation of objects and tfie establishment 
of associations and containment relationships among the 
objects. 

The Tool Interface 

From the tool perspective tlie database supports conoturency 
contral to the extent of allowing multiple readers and one 
writer. A reader can have up to 256 databases open for read- 
ing. The reader miLst structure queries witliin a transaction 
and is allowed to leave die database open w^hile it is being 
modified by a writer. The reader is notified of a change to 
the database \ia a callback when starting a transaction. 
Nested trmisactions aie not supported. 

The tool interface is a class libraiy that reflects tJie underly- 
ing object model. Each persistent object is presented as a 
liandlc. hitenially, each handle is mapped into a pointer to 
tlie real persistent object. All informatiori pertaining to the 
object is made available via mediods. Navigation among 
objects is sup ported by methods tliat return a handle or an 
itei'ator over a set of handles. For example, the following is 
a I partial fie fi nit ion of the Symbol class. 

clasB Symbol { 
public : 

Symbol ( Per Handle aymbolliandle ) ; 

Symbol { ) i 
-Symbol ( J ; 

// Namer kind and attributes of tbe symbol, 
char *Kaiiie [ ) const ; 
PerKind Kind ( ) const ^ 
Attributes Attrib() const,- 

// Enclosing scopes of the symbol. 
DBboolean EnclosingFile (File &file) const? 
DBboolean End ofiingBlock( Block tblock) 
const; 

// Iterator to all reference lists for this 
// Symbol. 

ITERATOR ( Re fLi St J RefListst) const; 



protected; 

PerHandle SynibolHaiidle; 



}/ 



The glottal SymboiTabie is the root for till nawgatix^n. Tliis ob- 
jeet provides navigation aiitl liasheti sear calling tt> all globally 
scoped symbols. The loUowing code segment illustrates how 
10 access all globally scoped functioiis from tJie global SymboJ- 
TaWe. 

SymbolTab 1 e e ymt ab ; 

// Construct an iterator over all global 

// functions. 

ITERATOR I Function) functionxtr = 

symtab . Global Functions ( } ; 
// For eacli function print its name and if the 
// function is defined, the file in which it is 
// defined, 
ITERATE BEGIN (functionitr) { 

File sourcefxle; 

print f ( "^s" f funct ionitr ,NaJTte ( ) ) ; 

if [ f unc t ioni t r . Enc los ingFi le { sourcef ile 3 3 
printf ('' contained in %q" , 
sourcef ile . Name ( ) ) ; 

printf ("\n") ; 
1 ITERATE_END(functionitr) 

All of the relationships among the semantic objects are first- 
level Hence, many of the interesting queries and rules wiU 
require a transitive closLiie* of the relationsiups. For exam- 
ple, eoasjder the following function, wliich prints all the 
deri^^ed classes of a given class. 

void derivedclasses {class theclass) f 

// Iterate over immediate derived classes of 
// theclaas . 
ATTRIBUTE_ITERATOR(Tag) tagaitr = 

els , DerivedClasses ( ) ? 
ITERATE_BEGIN( tagaitr) { 
// Print the class name, 
printf ("%s\n", tagaitr. Name () ) ; 
Class dercls; 

// Navigate to the actual derived class 
// and recursively call derivedc lasses to 
// print ita derived classes . 
if (tagaitr *CIassType i dercls ) ) 
derivedclasses (dercls) ; 
} I TERATE_Etro (tagaitr) 
> 



API Products 

The datal>ase APIs (apijli cation progranuiiing interfaces) ai'e 
available jrt the Soft Bench 4.0 product and are used internal- 
ly by the SoftBench parsers and tools. They are also used by 
some customers for compiler hnegralions. Tlie tool interface 
is the fimdaniental component of the software developer's 
toolkit for user-defined rules. 

' The tr^nsFttva cldfSUP€ fdra particular ohiject under a particular transitive biFrarv r^^laiioitshtp h 
tt^e set of objects descaixJed fionr the particular obj&ct by way of ihe particular relationship 
for example, if B is denved from A and C is disnved fmm B. the iransltive ciosuie for the ob|E3ct 
A under the reietionstiip "deri^red from*" (£ the sat of ohjecis whose elements are B and C, 



18 Fehruar>' 1997 Hew lelt-Piirkarid Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 



CodeAdvisor: Rule-Based C++ Defect 
Detection Using a Static Database 

C++ SoftBench CodeAdvisor is an automated error detection tool for the 
C-H- language. It uses detailed semantic information available in the 
SoftBench static database to delect high-level problems not typically 
found by compilers- This paper describes CodeAdvisor and identifies the 
advantages of static over run-time error checking. 

by Urnothy J, Duesmg and Johit fi, Dlamaut 



C++ is a powerful siicceasor to tlie C language that has all of 
C's features plus a lot more, mcliiding roiistnictors, destruc- 
tors, fuiu'tion overloatliiig, references, mlines, and others. 
VVith this added power come more options to manage, more 
ways to do things right, and inevitably, more ways to go 
wrong. C++ compilers can find s>ai tactical errors, but they 
dcj not tinfl enoi"s im'ohing constniels tliat are legal yet un- 
likely to lie what liie programmer intended, Ofien, problems 
of this nature are left to be found diirifig testing or by liie 
end user. Attempts to find these defects at an earlier and 
less expensive stage of development sometimes take the 
fonn of code iospectionsor walkthr*>iiglis. WiUe careful 
walkthroughs can nrul sonie of tliese errors, formiil iiispec- 
tious are timeHT'onsuming and so expensive that they are 
LLsually only applied to small pieces of tJie code. 

Since C++'s introduction in the early 1980s, a large body of 
experience with tbe language has accumulated and many 
works iiave a])peared that ilescnbe ronuuon pitialLs in I he 
huiguage ;ind ht>w to avoid tiieniJ' ' While sxnne of these 
problems can be qniiQ subtle, some of them aie also straight- 
forward enough tiiat a program can be created to detect them 
autoniatically ■' as lon^ as that program can bt» supplic*d with 
sttfTictenlly detailed information about tiu* code's stnK'tiue, 
The SoftBench static database (see article, page 1(3), with its 
semantic infomiation, provides an opporttmity to cTcale a 
tool that can do just that. Thi^ aiticle is about such a tf)ol: 
C++ SoftBench CotleAdvisor. 

CodeAdvisor: An Automated Role Checker 

CodeAdvisor (iistiils it.s knowledge of what are likely to be 
coding errors as a set of niles that idert tlie user to |>roblems 
such as calling virtiial functions from constructors, uTixing 
iosiream routines with std^a routuies, local variables ludin^ 
data members, and so on. Each nile is a set of instructions 
iluit qiH'iies the static^ database for the mft^nuation of interest 
and tlien performs the logic to test whether tlmi ptitcutial 
enor ctiudition is present. When it tietects a rule \ ioiation, 
CodeAdvisor displays the violation's location (file, line 
number) ii^ an error browser that lets the user navigate 
quickly and (*asily to tlu* problem site arul use an editor to 
correci it. (!!)nliiu' help is avaiiable U> tueseiU nujre ex|ilana- 
tion of the violation, possible ways to correct tlie probk^m, 
references for further infonnat ion, rmd whcui aptuofiriat e, 
c^xcepiiorus tt» the rule. 



CodeAdvisor detectJs Rile violaticjns by performing static 
analysis of the code using the SoftBench static database. 
Static analysis differs from tlte d>Tiamic or nm-time analysis 
done by debuggers, branch analyzers, and some ]7*^rfommnce 
tools in that all of the available code is exmnined. Dynamic 
analysis examines only code that is actually executed atid 
cannot, find defects m branches thai are never taken. Also, 
dynamic analysis requires that the co<.ie l>e far enough along 
so tJiai it can be actually executed. Static analysi^s, on the 
other hand, can be perfomieil as soon as the code compiles, 
even if the code cannot yet sttccessftilly nm. 

Because it is automated. CodeAdvisor will tirelessly check 
all the rules it knows aj*ainst all of the txxJe. This is practical 
only for relatively snuill pieces of code dtning inspections 
done l>y hand. Cnlike a huruaji code review^er, CodeAdvisor 
never gets so tired or iK^red thai it niisses a rule violation it's 
been progKimine*! to fit id. While CodeAdvisor cannot replace 
inspections comtiletetv (tJiere will alw'ays be problems that 
caniiol lie tletected automatically), itcnn be a good t oruple- 
ment to tradlt ional code inspections, freeing developers to 
fo<ais on iiigher-level problems by weeding out the detectable 
problents first. 

Example Rule: Members f^Udden by Local Variables or 
Parameters 

I jet's look at an example of one of the rules CodeAdvisor 
implenu^nts and exajnine how it uses the static database to 
find a nile violation. Consider the sruiill pnjgram in Fig, 1. 
The class Vehicle with its two-line metnber function SeiSpeed 
looks simpk* en(High. Tlie cimstntctor for Vetiicle sets the 
initial s])eed t(* zero, ho we would expect icj get a current 
speed of zerrj al the start or ihv pmgrMw anil we do. We might 
also exfiecl that, after cidling SetSpeed with a deita of 50, we 
woidd then get a current speed of 50. Hoveever. if we actn^iliy 
compile and run the progrmti we find that we stili get xero! 
Why? The pioblcm is thai a data member is hidden by a 
fimction parameter wilh the siune name. In SetSpeed weVe 
made an unlucky clioice wiien we named the piirameter 
speed, since there is a data member of the same name in the 
class Vetiicle. Wlien speed is tt»)dif1ed in SetSpeed, the ccmipiler 
modifies the imranuHer ratber tliai^ tlu^ tlata nu^mber. The 
compiler will not complain since we have given it unambig- 
tious instrudiuns, which it will follow perfectly If we had 
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# include <ioBtreain»li> 

clae» Vehicle { 
private I 

int speed; 
public ; 

iiit Cur ren t Speed [ ) conat { return speed; } 

void SetSpeed(int newepeed, int delta. = 0); 

Vehicle C) { speed =0; } 
}f 

// SetSpeed takes an absolute speed plus a 

// delta. If absolute speed ia aero, use 

// current speed. Other parameters should be 

// f2nd one defaults to 0) 

void Vehicle: ! SetSpeed (int speed, int delta) 

t 

if {! speed) speed = CurrentSpeed( J ; 

apeed ^ speed + delta; 
); 

inain [ ) 



Vehicle 


car; 




cout 


<< 


"Car ' s 


initial speed = " 




<< 


c ^r , Current Speed ( ) 




<< 


endl; 




car. 


SetSpeed ( 0, 


.50); 


cout 


<< 


"Car's 


new apeed 5^ " 




<< 


car . CurrentSpeed ( ) 




<< 


endl; 





Fig. 1. An example ofa (vOtieAdvisor rule Violation: members 
hidden by local variables or paraiiieters. 

chosen arty other name for our local variablej tile example 
would work as expeeted* 

Even in this simple setting, an error like this can be difficult 
to spot at a glance. In a more complex and perhaps more 
realistic situation, I his problem might never be found in a 
code inspection. If we bury a few subtle flefects like tliLs in 
a few megabj1:es of code we might tlntt that they won't be 
found until actual execution, exposes them as bugs. 

Detecting an Error Using the Static Databas^e 

The problem, then, is how to find these kintls of tlefects 
before llie user does. The context in which speed is used is 
w^hat's impojiant here. Using speed as a parameter in most 
cases is perfectly valid. Tlie only case we need to wony 
about is w^hen a parameter or loctU vailable is used wit hit) 
the scope of a member function and it has the same uante as 
a data member of tJiat class. Tills is where the static database 
is needed to make this Icind of rule checking possible. The 
static database contains, among many o\ tier things, infoixna- 
tion about what objects are global and local wiiliin a scope, 
and it imderstands what objects are member functions and 
what the associated pai^ameter list is. 

One way to create a rule to detect tliis paiticnlar error Is to 
first queiy Uie database to firid ail the classes in a progiam. 
Once w^e have all tlie classes, w^e can queiy the database for 
all the member fmicltoiis of those classes. Then we can 
examine each function's parameters and local variables 



looking for any members locat to the class or inherited pub- 
lic or jjrotected with the same name. If w^e fmd a match^ we 
report a rule violation and output tiic file and line numbers 
of tiie offending symbols. 

Of course, to make die iiile robust ^ there are still a few Uttle 
details that need to be considered in implenienting the above 
algoritlmv. For instance, to be general, when we query the 
database for classes, w^e'll want lo tlnri cktss temijiatcs as 
well, and if we fmd any, IpVc'U want to coasiiler only Uie tem- 
plates themselves and not Oieii- instances* Also, when we 
search for n^ember functions of these classes we'll want to 
skip any compiler-generated hmctions that the (1++ compiler 
may imve create*.! by default. We may also want to handle 
the cases where a symbol liides a member function as well 
as a data niemben All the infom^ation needed to handle 
these details is available in the ^tic database. 

Exceptions to the Mule 

The types of problems for which CodeAchisoi' is tiugeted 
aie not tiie obvious or even the filLscure abnsc^s of the 04-+ 
language. Compilers aj'e fully capat>le of fuiding these types 
of en'ors. Rather, CodeAd\dsor attempts to identify a more 
subtle kind of problem that might be charact eri^sed as con- 
structs that experience tells us m'f almost certainly not what 
die programmer intended, even though they aie fuhy legal 
within the huiguage. We musf uvcludc the word ''almost," 
however, because occasionally some of the most ui^kely 
constructs are in fact what, lite programmer intended. Decid- 
mg with certainty w^hether ctr not a suspicious constJiict v^dll 
turn out to be a real problem may sometimes require knowl- 
edge that ciuuiot be determined by a practical amount (or 
sometimes any ;^mount!} of analysis, static or run-time. 

To ihustnite this, consider, for example, the CodeAd\1sor 
rule that detects classes that are passed as a value parameter 
to a fnnctioit. Tliis may become a problem wiien the class 
passed is a derivefi class and \irtutil functions of that class 
ai'e called mthin tliai fund ion. This is because ctdls to diat 
class's \irtiial f mictions will rail the base class's versions, 
not the derived class's versions. The above conditions are 
easy enougli to check for with the static database^ l:)Ut they 
alone do not guarantee an eiTor condition. If the function is 
never passed a derived class instance, no problem will occur 
In some special cases, stat ic analysis might be able to detect 
this additional condition but in f Jther cases invohing com- 
plex conditional branclung, detection wonki be impracfictd 
or impossible. Run-time analysis also migln lie able to detect 
this condition in special cases, but in cases of less tJian 100% 
branch coverage or conditional branching determined by 
many combinations tjf possible external data, detection 
again would he imtjractit al. In this particuhu- example, 
CodeAd\isor will report the rule violation even with 
imperfect information because even when Uie problem only 
potentially exists, it can cause a serious problem for later 
code mainuiiners. Each nUe, however, nmst be evaluated on 
its owm merit.s to consider the possible nuisance of false 
positives. 

tu this sense, the rules can be regai'ded as heuristic^ — tliat is^ 
good but not perfect guesses that a given piece of code Ls a 
genuhie error Fig. 2 illustrates the nature of the problem 



20 Februarj' 1997 Hewletl-Packard Jouma 



)Copr. 1949-1998 Hewlett-Packard Co. 



♦Icuriitic S«tisfieit ^^. 



RoitErrofs 



// 



RepofTed Real Eiron 



False 
Pcsrttvfts 



Undmeciett 



Fig. 2, The prohJem of fimling errors with miperfect mformaiioiL 

when a rule has imperfect knowlectge of the code. The area 
where a heiiristir rule is satisfied still contains cases where 
tio real enor exists. To report these cases when there is a 
reasonable aniotmt of imcertciinty as to their validity wouh! 
he to bombard the user with unwanted "noise" that would 
' I istract from other real problents. 

We have reduced tlie noise factor in CodeAdvisor by adopting 
a philosoplty of "'no false positives" when iniplenienting a 
nik\ Tlval is, when iniperfe<n infonnation prevents kiio\\1ng 
with certainty if a construct causes a problem in tiie current 
settiitg, the code is gi%en tlie benefit of tlte doubt unless 
there is also a serious potential for a future maintenance 
problem. In addition, for those occasional cases where a 
suspicious construct is repotted but still deemed acceptable 
by the user, CodeAd\Tsor pro\ides a filtering median ism to 
iiUow the user to suppress the display of particular violations. 



Siimmarj' 

CtM;ieAd\1sc:>r tisc^s die informaiion available in the Soft- 
Benrh static database to implement a deei>er te\el of error 
detection than is available with current compilers. Ccxle- 
Advisors static analj^'sis has advantages over run-time analy- 
sis because all of the a^-ailable code is analyzed instead of 
only the branches that are actually exe^;uted, .\n automated 
rule checking to(jl like CodeAd\isor can rcjntribute u> tbe 
code developmejit process at ^i early stage, where the cost 
of defect repair is less expensive. CodeAdvisor contpiements 
traciitional ccjde inspection and testingj aUowijig developers 
to focus on tlie higlier-level problems by weeding out the 
detectable problems firsL 
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Using SoftBench to Integrate 
Heterogeneous Software Development 
Environments 



Migrating from mainframe-based computing to client/server-based 
computing can result in a heterogeneous collection of machines that 
do not interoperate, forcing software developers to deal with unfamiliar 
system commands and systems that cannot share data. A SoftBench 

control daemon Is described that enables developers to integrate 
heterogeneous computing systems into efficient, tightly coupled software 
development environments with consistent, easy-to-use graphical user 
interfaces across all machines. 

by Stephen A. Williams 



Many companies today are migrating from mtiinfraitie-based 
romputlng environments to client/sen er-based technologies 
using vai-ions workstations and PCs. Tliey me attracted to 
the cJientyseiver architecture because of Jndust r:^ claims of 
benefits like increased erficiency lower operating costs, and 
less reliance on a pailicular vendor. 

Often, however, the result is a heterogeneous collection of 
machines that do not interoperate well. Because the operat- 
ing systems on the disparate machines all come with their 
ovm sets of tools, software developers must leani a new set 
of commaiTds for each system that they use. In addidon, 
developers must deal with the inconsistencies that arise 
w^hen applications available on one system are not available 
on another and when data carniot be shaied betw^een ma- 
clnnes because the different toolsets caimot communicate. 

To solve these problems, the advanced system development 
tmd integration division of Science Applications Inter- 
national Cor]ioration (SAIC) uses He wletr- Packard's Soft- 
Bencli product to integrate its customers' divei-se systems 
into efTicient, tightly coupled soil ware development environ- 
ments with consistent, easy-lo-use grajahical user inteifaces. 
This article discusses why and how Sj\1C uses SoftBench to 
solve Its customers' mnltiplatfonn softw^are development 
problems. The article deTails some of the common pitfalls 
encountered wlven developing software in an open systems 
en\1roimient, explains how SAIC deploys SoftBench to inte- 
grate such systems, and concludes by discussing the benefits 
of such an integration. 

Open Systems 

Companies are adopting client/ser\^er-based open systems 
for a wide variety- of reasons. Some companies hope to 
increase computing efficiency by distributii\g die data and 
processing load, thereby providing faster resiionse tinges 
and quicker access to system resoioccs. Other contpanies 
want to lower theh development costs by using lower-cost, 
yet faster workstations and PCs. Yet others must move to 



open systems to remain compatible with their customers 
and keep a competitive edge in the marketplace, 

Wiile migrations to open systems can provide great di vi- 
deo cb, tiiey can also become more miwieldy than t he systems 
they replace. Many client/server topologies contain a wide 
vaiiety of Ttujchines. such as Mgh-end serv^ei^s running the 
LlMX® oper'at ing system, PCs nimiing IVlicrosoft -'Windows, 
and legacy systems n^nning proprietary operating systems. 
In addition, even smiiiai- machines will often run different 
operating systems (eg., vaiiations of the liNLX operating 
system) or even different versions of the saane operating 
system^ llie resulting heterogeneous collection of machines 
makes it difriciilt to create an efiicient and cooperative soft- 
w^aie dev^elopment environntent. Fig. 1 depicts an example 
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Fig. 1. All example of a heterogeneous collection of mat-hines in 
which the applications on different sj^^sienis cannot coopemte or 
communicate with each other. 
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of such an efivironment Note that most amplications cannot 
conimunjcaie i^ith each other. 

Although many open sj-'stem standards exist to help such 
diverse collections of ntat tunes communicaie, most of them 
are low-level network standards that simply provide a way 
for bits to be transferred between machines. The open sys- 
tems conununity still lacks accepted hi^-level application 
standards thai would allow disparate programs to interact 
with each otiier. Thus, applications from differenf vendors 
often cannof interoperate, wliich greatly restricts the bene- 
fits of implementing many clientysener solutions. This lack 
of communication also means that data must be replicated 

(Toas madiines* wasting resources and increasing the risk 

1 data inconsistency* 

.Mother problem with de\-eloping in a multiplatfomi, miiltJ- 
xendor environment is I he lack of consistency in the user 
interface to O^e systems. Bet*ause developers mim tleal with 
miilUple operating systems, they ha^^e to learn how to operate 
each systems inlerface individiuilly. This can he an especially 
fonnidable task cunsitlering the arcane commands used by 
some o|)eraUng systems atid the differences hetw^een file 
systems across platforms (i.e., hierarclucai versus fixed 
depth. / versus V etc. ). Developers must also remember 
wMch system t ontains each application that they need^ 
where it is located, ajid how to siarr, it. 

Furthermore, developers in a heterogeneous enviromnent 
miLsl learn liow to operate the vtitTerent user interfaces for 
eacii of the appJicaticjiis that tliey use. ^^Iiile some applica- 
tions now' liave elegant graphical user iuterfaces, the look 
and feel of each system are often different. Also, many ii|jpli- 
cations do not have graphical user interfaces at alJ^ which 
requires that developers memorize command-line fjptions to 
these programs, Tliese inconsistencies not tjnly lengthen a 
<levelopcr's leiirning ('ur%c, but also make developers less 
effic^ient when switching between applications. 

Integration 

Previous issues of the HP Journal have described lujw to 
use Sf>ft Bench to integrate tlisparate applications nimiing 
under the HP-ITX* and Solaris opei^ating systems. ^^"^^'^ In this 
article w^e will concentrate on how to use BofLBench to inte- 
grate apphcations running on other platfonns. Tlie key to 
accomplishmg this integration is to port SoflBench's subprn- 
c^ess contiol (iaemon ( SPC!DJ to each operating system that 
is to be integrated. The SPCD pro\ides a standard, robust, 
and secure method of executing suhprfK'csses on remote 
systems. Tliis is acconiphshed by providing an API iliroiigh 
which encapsuiat ions can interact witli dieSPCT) fiver a net- 
work socket connectioru Throitgh the API, encapsuJations 
can instruct the SPCD to start or stop a snbprocess on the 
remote maciTine, serul input to a suhproeess, and receive 
oulpiit from a subprot^ess. 

Thus, once the SPC'D Ls ported to a given system, enc-apsula- 
tionst c;m be wTitten for applications miming on that system 
as easily as if die applications were running on aJi HP-L X or 
Solaris system numing SoftBench. 

f A Soft6#ndi encapsulatian means integrating & tool into ;he HP tool mtegrataon afctiiiaciure. 



Why SoftBench? There are se^^eral reasons w^hy SAIC chose 
lo use Scjfi Bench to integrate heterogeneous software devel- 
opment en\ironmenis. First, the standard SoftBench envi- 
ronment corn^ with a rich set of stateK>f-ihe-art soflware 
development tools, all of which use a consistent, easy-to-use 
graphical use^ interface. In addition, SoflBench provides a 
^^hlcal user interface lo the operating sj*stem (via tlie 
SoftBench development manager) which hides many of the 
intricacies of the operating system and its fiJe system. 

Another advantage to using SoflBench is the framework for 
interapplication conununic^tion it provides throu^ Soft- 
Bench's broadcast message server. This framework allows 
applications witli no direct know1e<Ige of each otl\er to com- 
municate and therefore interoperate. Tliis functionality 
allows one application to be substituted for another witii no 
adv^erse effects on odier applications. It also allows new 
applications to be integrated into I he envlroiutient without 
making any changes to existing apphcations. 

Probal;)ly tlie most important reason to use SoftBench is its 
extei\sibility. Thiough the use of the encapsulator librcit>", 
which pro%ides functions to communicate \^1th the SPCDs, 
the SoftBench envirtmnient caji be extended to include non- 
SoftBench applica!i(ms. In addition, the encapsulated apph- 
cations can nin on any operating system to w^hich the SPCD 
has been ported. 

tJsing SoftBench for Integration. Given die above reasons for 
using SoftBenc^h to integrate a heterogeneous software 
development environmenip how does one go about imple- 
menting such an int egratitm? The first step is to install Soft- 
Bench on at least one HP or Sun workstation. Note that it is 
not ttecessar>' to place such a workstation on eacii tleve top- 
er's ilesk because SoftBench can he run remotely using the 
X Window Sy.stem and fle^elopers can use rmy machine nm- 
iiiiig an X sen-er. Tliis inchides DOS, Windows, MarOS, rUid 
most versions of the 1 tnIX operating system. Thus, a com- 
pany implementing a Soft Bencli t^nvironment can probably 
leverage much of its existing hardware inventory to keep 
costs down. 

Next, the SPCD needs to be ported to each fjpe rating system 
in the environment that, ctjntmns applications that need to 
be integrated. Of course, there's no need to port In llP-rX t>r 
Solaris since SoftBench (and thus the SPCD J already runs 
on those systems. As discussed earlier, the SPCD provides a 
standard method that SoftBencti applications can use to 
execute siibtjn>cesses on remote systems. Althtnigh ofher 
metlicMis of remote snbprocess control ctjuld be used in such 
an integration, lire SPCTJ is prol>al>ly the best c^hoice liecause 
it is specifically designed to work with SoftBench, Also, note 
that there is no need to port till of SoftBench since only the 
SPCD is needed for remote subprocess control. 

Because the source code for the SPCD is not freely avail- 
aJ^le, the SfHD can fjtily be ported by Hewlett- Packard or its 
authorised agents. SAIC has been granted such autiiorily in 
the past to complete SoftBench integrations for a numt>er of 
its customers. The* (Operating systems to which SAIC has 
already completed die SPCD ports mclude: 
• UNIXWjire 
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• MP-RAS 
•VMS 

• pyramid DC/OSx 

• Strains FTX 

• Windows NT 

• Tkndem Guardian 

• Tandem OSS, 

A port to MVS was started but not completed. 

As can i>e seen from the diversify of the operating systems 
to which tlie SFC'D has already heen porled. the SPCD code 
is quite portable. Howe% er, there are a number of requiie- 
ments diat the SP( D makes of a target operat ing system. 
The list below details the basic requirements that SAIC uses 
ttJ determine tlie level of effort in an SPCD port; 

• An ANSI C compiler 

• A C++ compiler 

• A Berkeley-type TCP/IP sockets capabiJity 

• The capabihty for a process to start up and conmiunicate 
with several subprocesses like the UNIX forkd and piped 
system calls 

• The capability for a process to detect input from several 
sources at the same time like the UNIX select(l system call 

• An interface that allows system calls to be made from C 

• A way to set the enwronment of a controlled process like 
the UNIX getenvi) system call 

• Functionality^ similar to the UNIX inetd server 

• Network File System (NFS) capability. 

Note that the SPCD has Ijeen ported to envuronments tliat do 
not Imve fork(L selectO, the inetd server, or NFS. Wiile these 
items do make the port much simpler, it is still possible to 
port to emironments that do not include all of tiie items 
listed above. 

Once the SPCD has been ported to the appropriate operating 
systems, custom encapsulations must be written for each of 
the apjihcatiojis to be integi'ated ijilo llie SoftBench envlrorv 
ment. Each encapsulation's job is to aei as an intcnnediaiy 
between a non-SoftBencli apphcation and tlie SoftBench 
environment, making it look like the application is a fully 
mtegrated SoftBench tool (see Fig, 2). Performing tliis job 
entails a number of responsibilities, such as starting the ap- 
phcation to be integrated, establishing a connection to the 
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Fig. 2, TiiD orgaiuzation of somvart' coinpunents after SoftBench 
k set up. Tlie SPCD has been ported to a legacy system, and an 
encapsulation has been ^vrltten for each legacy application to be 
integmied in thp SoftBench emlronnient. 



Sofi Bench environment, and sendmg the appropriate nolifi* 
cation messages to SoftBench whenever the enca^>siilated 
application perfoniis an action about winch another tool 
might want to know. Furthermore, the encapsulation must 
listen for messages retiuesting a service of riie encapsulated 
appUc ation and then instinct the apphcation lo perform tlie 
requested task. 

To sirn]>litV the process of writing an encapsulation, Soft- 
Bench comes witli mi enf:apsulator library' that provides an 
easy-to-use API to the SoftBench environment. The encapsu- 
lator library provides fimctions to: 

• Send and receive SoftBench messages through the BMS 

• Control remote subprocesses using the SPCD 

■ Create graphical user interfaces thai are consistent with 
other SoftBench tools. 

Because the encapsulator Ubrary has only been ported to 
the HP-irX and Solai'is operating systems, encapsulations 
that link with encapsn later routines must run on a machine 
using HP-UX or Solaris. While the encapsulator library could 
be poHed to odier operatii>g systems, this is usually umieces- 
saty since an encap.su lation can use the SPCD to execute a 
subprocess on a remote host as easily as on a local host. 
This is one of the ni^or advantages gained by poiting the 
SPCD to all operating systems m the environment. 

A few other Ihnitmg factors must be taken mto account 
when writing encapsulations. Firstn it is difficult, if not im- 
possible j to uitegrate applications that have no conm^and- 
line interface. For cxajnple, if the only way to interact with 
an application is tluough a graphical tiser mterface, theit an 
encapsulation of that application nmst enmlatc mouse 
movements and Imlton clicks to communicate with it. This 
is generally not a feasible option. 

Another factor to consider when writing encapsulations is 
the grannlanty of the information provided by the applica- 
tion to be encapstilated. If the application does not give 
some sort of notification for each action that it takes, then 
U\e encapsulation will be littntetl in its inteipretation of what 
the application is douig. For more information about the 
limitations of the encapsulator library see reference L 

Once the necessaiy encapsulations have been v^Tittcn, the 
next step in integrating an apphcation ijUo a heterogeneous 
coni|.Hit:ing emironn^ent is to extend the Soft Bench cmiron- 
ment so that aO of tiie desired applications are seamlessly 
integrated into it. This is acconiplisiied by modifying the 
SoftBench configuration file sottint to include references to 
each of the new encapsulations (sec Ing. 3). This action 
informs SoftBench about tlie new functionality Hiat is now 
available through the encapsulations and how to access 
those encapsulations. 

Modifications to softtnit can also be used to uiform SoftBench 
to replace exist uig tools i\dth new encapsulations. For in- 
stance, the stimdard e-mail tool tjtat conies with SoftBench 
could be replaced with an encapsulation of a locaJ e-n^ail 
application. S.\IC has used tiiis capability to replace the de- 
buj^er tiiat comes with SoftBench with an encapsulation of 
the GXC debugger, gdh. This pro\ides SAlC's customer with 
a fully integrated debugger tliat runs on any maclune tiiat gdb 
suppons, which mcludes most modem operating systems. 
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$H01fB/.ffo£tiiiit ^ — user custoaiizatiQiLa 
So ft Bench initialization 



i Sditor 



# To use "vi** as the editor, 

# fol lowing liJie 

EDl^ TOOX. KET * %Local% aoftvierv 
a«t -types ^Types% 



uncc^maent the 



-scope 



# To use ''softedit*' 
# foil owing line 
tEDIT TOOL RET 
net -t^rpeB %Types% 



as the editor, uncoinmeiit the 



%IjOcal% softeditsrv -scope 



# To use "emace" as the editor, iincomiiieiit the 

# foil owing line 

#EDXT TOOL NET * %Local% emacs 



# Configuration Management 



DM TOOL DIH * teflon softdm 
-dir %Directory% -file ^File% 



-host %Host% 



# To use "RCS" as the CM tool* unconmient the 

# following line 

CM TOOL NET * teflon softrcs -scope net 

# To use "SCCS" as the CM tool, uncomment the 

# following line 

#CM TOOL NET * spike softsccs 



# Debugger 
# 

# To use GDB as the debugger, uncomment the 

# following line 

#DEBnG TOOL FILE * teflon /usr37Btevew/ 
ttDebugBackends/fioftgdL/aoftgdb -d 255 -1 /ttn^/ 
Boftgdb.log -host %Host^ -dir %Directory% -file 
%File\ 



Tandem stuff 



# To startup RSHELLSRV in debugging mode, 

# uncoimiient the following line 
tRSHELLSRV TOOL HOST * teflon /usr/rshellarv/ 
#rshellsrv -d 255 

1 /tmp/Xog,rshell3rv,%Host%.$DSER -host %Host% 

# To startup RSHELLSRV in standard mode* 
#uncojmnent the following line 

RSHELLSRV TOOL HOST * teflon /usr/rehel Isrv/ 
rshellsrv -host ^Host% 

Fig, 3. A SoftBeiicK coiifi^iiraliort tile softinil Tins filr contains 
rcFeroiK-es to e^ch n^w enrapHulalion. 

Ti> fm-ilipr integrate a development environment, the Soft- 
Bench nu'ssaf^e connector caii be used to automate repeti- 
tive tsaks ii\u\ eiUbree s<*rtvvai*e tlevelopinerit [jroeesstvs. The 



measstgis connector works by monitoring the BMS for a d^ 
sired message and then e=xernting a user-supphed routine 
whenever thai message is seen. For example, suppose com- 
pany ix»lic\'^ requires that a complexity' analysis prograni be 
nin on all source code when it is checked iiito the configura- 
tion manager. To meet that requirement lAiih no human in- 
tervention, the message t^oimector couid t^e configured to 
monitor the BXIS for a message ftt>m the configuration man- 
agement tool iudirating thai a file has ja^t betm checked in. 
Then, it would run tiie analysis program on ttiat iile. perhaps 
e-mailing the results back to the devetoper who checked in 
the rile. 

For software devetopment processes that require more iniii- 
cate mteractions than tlte message connector can pro\1de, 
Sx\lC*s SjiierVision product can be used, ll provides a t^ext- 
generation process management envirtjiunent timt helps 
teams manage the software engineering process, including 
such tasks as writing nev^' software, debugging programs, 
niaintiiining existing systems, and porting to new plattbrms. 
Also, because Syner\'isloi^ fully sui)iit)rts the SoftBencli en- 
viron meni^ no new encapsulations need to be written for it. 

Note that the steps described above for integrating a hetero- 
geneous software development envlronmenl with SoftBench 
do not need to be implemente<i all at once. Instead, the 
buik-in extensibility of SoftBench allows one to take a pro- 
gressive approach wherein applications are encapstiiated 
one at a time and added to the environment as they arc com- 
pleted. Such an appi'oach can smooth the migration path 
Grom a legac^^ system to an open system by eUniinating the 
need for a complete sv^itchover to the new technology. 

Benefits of Integration with SoftBench 

By extending Sot^ Bench as described above, a heteroge- 
neous collection of computing sysleuns with disparate, in- 
conipatible tools can be tn^msfomied hitri iin efficient^ tightly 
coupled softw^are development environment with cottsistent. 
easy-to-use graphical user inlerfaccs across all machines. 
Pig. 4 si lows the n*suil of an cxamixle integral inn. 

Certainly, one of the biggest advantages of integrating with 
SoftBench is ihc rcali^aiion of a stfuidard, consistent user 
inleiface to all lools on all machiues. This consistenl inter- 
face miniituzes the learning cinvT for developers by reduc- 
ing tlie mmiber of conmiands that ttiey need to team to use 
the environmi'm. It also improves theefficiency of develop- 
ers Ijy sifuplifyittg their interactions with bnth apph cat ions 
and operatittg systenis and by providing a means for data 
sharing between appUcations (e.g., cut and paste, drag and 
drop, etc.). In environments with legacy systems where 
ttevelopers have* been using text-based terminals, ttie benefit 
of tk'ds grapttical user interface can be enormous. 

As discussed earlier, all S<jrtl^ent^h applications use the 
X Window System to display tiieir gra|>hicai user interiaces. 
This pro\ides the adv^antage that the complete software de* 
velopment environment is ahsays available from any machine 
that has an X serv-en Funhermore, the environment lor»ks 
mid wfirks exactly the same no nuitter what machine a tie- 
vclojier uses, fron* a MacitUosh PowerBook kijjtoii nnitiing 
an X st^rver to an UP 9000 workstation runnii^g MP Vm\. 
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An environment integrated with SoftBench also provides the 
advantage that remote fiat a access is transparent to the user. 
By using NFS and the aytoriiounter SoftBench autotnatically 
retrieves data from remote macliines i^ithoot any user inter- 
vention. Developers only need to speciiy wMch niaclnne 
contains the desired data, and SoftBench handies the rest. 
This benefits developers because tJiey do not have to copy 
files back imd forth belweeii machines or know the intrica- 
cies of networked fiJe systems. 

Similarly, SoftBench provides the advantage that remote 
program execution is transparent to tJie user. By using SPCD, 
SoftBench can execute ai>pli cations on remote machines 
without developer intervention. Developers no longer need 
to log mto various machines to run the tools they need be- 
cause SoftBench pro\ides a centralized conti'ol center that 
places all tools at their fingettips. Tins let,s the developer 
concentrate on the t^isk at hand instead of w^orrjing about 
logins, passwords, patlmames, and so on. 

By pro\1ding transparent access to both data and apphca- 
tions, SoftBench allows resources to be spread across a 
distributed client/serv^er topology without introducing com- 
plexity into its use. Developers get a unified view^ of their 
emironmeni whether it contains one machine or one hmi- 
dred, whether all their data is centralized on one serv^er or 
distributed across rrimiy systems. In atldition, machines can 
be atided lo (or removed from) the environment with out 
impacting developers simply by modif\ing SoftBench io lise 
(or Slop using) the given machines. 

Another advantage of kitegrating with SoftBench is the rich 
set of state-of-t lie-art software development tools that come 
wifti SoftBench. Tliese tools benefit developers by simpli^^g 



CDnJiguraliqiii 
ManagemeiTt 



Fig, 4, An example of an integra- 
tion over ^eveiral platforms. Note 
that there is an eneapsuiadon for 
eafjh application. 



and expedifing the edit-compile-debug cycle. The tx>ols auto- 
mate processes such as checking source files into and out of 
configuration management, bttilding executables, and dis- 
playing erroi^s found by the comi>ilen In addirion. die tools 
can pro\1rie a graphical \iew of sonice code, allowing a de- 
veloper to quickly learn imftimiliar code or iind eiTors in 
program flow, 

Fuithemiore, by encapsidating local and third-paitj^ applica- 
tions in the emironment, tievelopers %vill have access to 
those applications as easily as if they were standajxl Soft- 
Bench tools. Tliis benefits developers because they do not 
have to know on whicli host the applications exist or how to 
start, them. Instead, the developer can start an application 
simply by selecting it from tJie list of applications in the 
SoftBench tool manager. In fact, by customizmg the environ- 
ment with the niessage connector, many applications can be 
started automatically. 

As discussed eartier, the message comiector and Syner- 
Vision can save developers time and effort by automating 
repetitive tasks and by enforcing softrv^'are development poli- 
cies such as ensuring that required tasks always occur and 
that tiiose tasks aJ*e executed in the proper order. By eitforc- 
in^ weE-defined policies, SoltBench cmi help increase the 
efficiency of tiie software development process and improve 
the quality of the finished product. 

Conclusion 

Soft ware development m a heterogeneous computing envi- 
ronment can be a difticuh proposition. Vaiying ha2-dwaj*e 
and software platforms, incompatible tools, and ijiconsistent 
user interfaces are just a few of the trouble spots. However, 
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flewlett 'Packard's SoftBench product can be used to solve 

these problenis by pro\'iding a stair dard upon which to inte- 
grate the rtisparaie components of such an einironmeiu. By 
porting SoftBench's SPCD to each openiting sv-steni involved, 
all niachities become equally and consisteniiy accessible 
from SoftBench. Then, by encapsulating the applications on 
those sjiiten^. the applicafion.^ Ijerome fuUy integrated 
Soft Bench tools <'apable of interacting ^vith other SoftBencJi 
tools. 
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The Supply Chain Approach to 
Planning and Procurement 
Management 



The supply chain approach models stochastic events influencing a 
manufacturing organization s shipment and inventor/ performance in the 
same way that a mechanical engineer models tolerance buildup in a new 
product design. The objectives are to minimize on-hand inventory and 
optimize supplier response times. 

hy Gregory A. Kruger 



This paper describes the processes and equations behind a 
reeiigineering effort bcgim tri 1995 in the plaiining tuxd pro- 
ciu'emenl orgaiilzalions of the Hewlett-Packard Colorado 
Springs Division. The project was known as the supply 
chain project. Its objectives were to provide the plaiiiiing 
and procurement organisations with a rnelhodolog>^ forset- 
tuig the t>esi possible plans, procuring the appropriate 
amount of material to support, those plans, and making up- 
front business decisions on the costs of inventory versus 
supplier response time (SRT)/^ senice level to SRT objec- 
tives, future detnanti uncerialntyt part. lead tinies, and part 
deliverj^ imcertainty. The statisticaJ modeling assumptions, 
equations, and eqiiation derivations are dormnented here. 

Basic Situation 

Consider a factory builciing some arbitrjuy product to meet 
anticipated customer demand. Since I'utm'e demand is always 
an uncertaint^^ plajiningand procurement must wTestle with 
the task of setting plaixs at the right level and proem ing the 
appropriate material. The org^mization strives to run tlie lac- 
toiy betw-een tw^o equally unattractive scenarios: not enougit 
inventor^' and long SRTs, or excessive inventory but meeting 
SRT goals. In fact, more tlian one organization has found 
itself with the worst of both worlds — huge inventories and 
poor SRI^. 

Tiie supply chain project focused on characterizing tlie vari- 
ous stochastic events influencing a manufact tiring orgmiiza- 
tion's siiipnient and inventory performance, niodehng them 
iinalogously to the w^ay a mecliajiiciil engineer would model 
a tolerance buikiup in a new product design. 

Problem Formulation 

For a particulai' product, a factoiy will mcur some actual 
demand each week, that is, it w ill ijiciu- demand l\ in week i, 
for i = 1, 2, 3, .., From a plamiing and proemement perspec- 
tive, the problem is that looking into the futme tJie Dj are 
miknowTt. 

' In siandard terminDlogy, SflT siands for "supplier response time." frr iJiis case, a better term 
WDutd be "shrpmem response bme." because The supplier bemg refened la \t HP and not one 
□f HP's suppJiers. In i^ts paper, we use the stantiard termmology fur SRT bai the wvord "syppii- 
bt' in gli other coniejfts means um of H?'t suppliers 



Let P] he ihe plan (or forecast) for week i in the riitiir'e. Now 
for each week, the actual demand can be expressed as ttie 
pLamied denumd plus some error: Dj = P^ + ei. 

The MRP (material requirements planning) system, rumiing 
ill inter\^als of R w^eeks. ev^ilnates whether to order more 
material to cover antic ipaied tk^mand, and if the decision is 
to order, how mucli to order, C Jiven a lead time of L weeks to 
take deliveiy of an order jxlaced to a supplier now for some 
part., tbe material in the supply pipeline must cover rea! de- 
mand for the next L + R weeks. By supply pipeline we mean 
the quajitity of tJie part already on liand at tlie faclor>^ ]>ius 
the qumitity in orders placed to the suppher and due for 
delivery over the iiext L weeks. 

For simplicity, lissome for the renuiinder of this disc iission 
that we are dealing with apart unique to one produci and 
used only once in tjuilding the product. We will remove 
tliese constraint .s later L>ut for now it will help to focus on 
the key concepts. 

Define X to l>e tlie imkno\^Ti but actual demand the factory 
will exjierience for this pari over the next L + R weeks: 



L+R 



L+R 



X= lDi= I(Pi + 4 



In statistical terminology, X is a random variable, that is, we 
crnmot say with certainty the value it will take next, but with 
some assimiptions ahout the natme of the plmming errors 
(ej), the distribution of X can h>e charart erized. Specifically, 
we wWi make the assmnption that die e\ sre distributed 
according to the Gaussian (normal) distribution with mean 
zero mid variance a^ (see Fig. I). The assumption that Uie 
mean of the e^ is zero says that tjur plans are unbiased, that 
is, the factory is not consistently overestimating or imder- 
estimathig future demand. Tims, llie average of the differ- 
ences between the phm mid the actual demand over a rea- 
sonable period of time woiUd be about zero. The normal 
distribution is symmetric, so we are saying there is equal 
probability in any week of actual demand f>eing above or 
below phm. The variance measm-es how large tbe planning 
errors can get in either direction from zero. 
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Fig- 1, Assyjned normaJ disiribytsoii of planning ermrs. 

We would like to know both the expected v^ue of X and its 

\'arianc'e. Knowing these two \^ij£*s ^^ill fomi tlie basis for 
tlw ultimate decision rules for repienislmient order sizes 
placed to the supplier for our part- 

We will use the follo^^ing notation: E(x) represents the ex- 
pected value of the random variable x, and V{x) represents 
the variance of the i-andom variable x. 

Before launching into the derivation of the expected value 
of the real demand over the nexl L + R weeks, note tJ^l L 
itself is a random variable. ^Tien an order is placed with tiie 
sujJt^lien delivery does not always come exactly on the 
atknowledgnienl date. There is some imcertainty associated 
witli when the repletufilintent ortier will arrive. Like the 
planning errors, we will assume that the delivery errors are 
noniially distributed about zero. Thus: 



ECX)-e( l^lPi + eO) ^ X ^( 



Pi + eil 



= I (E(Pt) + E(ei)) = V Pi. 

lite result will be precisely correct when the Pj are sration- 
s^ry (that is. the pian is a constant riin rate) ^md will serv'C as 
an approximation when the Pi are nonstalionaiy. 

Defer mining tlte variance of X is iitore involved because the 
limit of the summation. L + R, is a random variable. The deri- 
vation can be be found in Appendix L The result is: 

where a^^ is tbe standard deviation of the errors e^, o^ is the 
standfu-d deviation of L, and P^, + k ^^ *^i^ average of the plan 
over L + H weeks. 

The standard deviation of demand is the st|uare root of this 
result. Ii\ practice, we estimate tlie standai'd de\Hation of 
deniand by: 



where E is the average lead time from the supplier of this 
part, R is the re%1ew period, sf^^ is the \iiriance of the differ- 
ence betvi^een the weekly plan and the actual weekly demand, 
and s|£ is the variance of the difference between the date 
requested and the date received. Lee. Billington, and Carter^ 
give the same result when niodeiing the deniand at a distribu- 
tion center within a supply chairt 

Kno^\ing the variance of the demand uncertainty' over L+R 
weeks, we can develop a decision rule for detemiining the 
amount of tnventorj* to carry to meet the actual demand the 
desired percent of the iime. 

We define the otxier-up-to levej asr 



Order-up-to Level = > Pj + Zi^^ox, 



i=i 



0x - ^'(L + Hjsf,t: + Pl+r^!e» 



where Zi_[jis tlie standard normal \'aiue corresponding to a 
probability a of slocking ouL Zi^tdx is called the safety 
stock. 

We define the invenloty position as follows: 

Inventory Position = On-Hand Quantity 

+ On-()rder Quantity 

- Back-Ordered Quantity. 

The purchase order size decision rule each R weeks for 
replenishment of this part becomes: 

New Order Quantity = Order-up-to Level 

— Inventorj^ Position. 

We are simply trying to keep the order-ui>to level of matjenal 
ui the siijjply jjipeline over the next L+R weeks, knowing 
we ha\e a probability a of stocking out. 

As you can see^ the basic idea behind the statistical calcula- 
tion of safety stock is straight ft jnvarfl. In practice, a number 
of c^omplicating factoiis must he accoujUed for before we 
can make this technoJogy operational. The list of issues 
includes: 

• The chosen frame of reference for defining at\d measuring 
future demand uncedahuy 

• Tlie impact of SRT objectives on inventory reciuirements 

• Tlie translation fnmi ]>arT service levej to finishe(i (iroduct 
semce level 

• Apprfjpriate estimates for deniand and siii>p!y uncertainty 
upon which to base the safety stock calculations 

• Pincbasing constraints when buying from suppliers 

• The hitlden effect of review period on service level 
perfo nuance 

• The flefmition of service level 

There are significant biLstness omconu's from managing 
inventory with ihe statistical calculation of safety slock 
These iiK^lude the ability to: 

• Predict avet-age on-luimi inventory and the range over 
which fjhysical invcntoiy can be expected to vary 

• Trade off service level anti inventory 

• TYade off SRT and inventory 
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"From Loading" 
|fiino1ii>ns as Safety Stack} 



Time 

Fig. 2. Many mariufactiiring pkiiiiiiifi r^rgajli^atians hanfUe \he 
uriGertaiiities of future demEuid by intent ionally drmng the inaterial 
requirements plait (MRP) higJier than expected orders. 

• Plot order agiiig curves so that you can see how lor^g 
customers may ha%^e to wait when stork-outs do occur 

• Measure the inripact of reducing lead tinies. forecasting 
error, and deliver>^ uncertainty^ 

• Meastire the hnpact of changing rp\1e^v periods and 
niinhuuin order quantities to the supplier 

• Stabilize lite orders placed to suppliers so that tiiey are 
not being subjected to tindue uncertainties 

• Eeduce procurement overhead required for manipulatii^g 
orders. 

Tiirning off the Production Plan Overdrive 

Many mauulacun1t\g plannuig orgiuiizations have traditiomdly 
handled die uncertainiles of future demand by mtentionaliy 
putting a neai-term overdrive into the production plan (see 
Fig. 2). By dri\ing the niaterial re<iuireuients plan (MRP) 
higher than expected ordei-s, a buffer of additional mateilal 
is i>tougii1 mto the factory to guard agaitist tlie iiu^vi table 
differettces between forecast and actual demand. In effect, 
this overdrive J or front loadLtig, functions as safety stock, 
although it is never cfilled that by the materials system. 

While this practice has helped many fadjories meet shipment 
demaiids, il has also caused frustrations with nonoptimal 
inventor>^ levels. Biasing the build plan liigh across all profl- 
nets does not consider that it is imhkcly that all of the j prod- 
ucts will be simultaneously alcove their respective forecasts. 
Therefore, mvcntories on parts common to several products 
tend to be excessive. Also, tliis approach treats all parts the 
same regarrlless of part lead times, rather titan allocating 
safety stock inventory based upon each pait's procurement 
lead time. The factory can easily end up with inventories too 



high on short lead time paits bskI loo low on longer lead time 
parts. Finally, the practice of building a front-end overdrive 
into the plan can lead to conOict between the procurement 
^ and production planning departments. Wanting to ensure 
sitfScient material to meet ctist.onier demand, the planning 
departments natural desire is to add a comfortable pad to 
the production plan. Procurement, aware of tlie built-ui over- 
drive in the plan and under presstjre to redttce inventories^ 
may elect to second-guess tlie MRP system and order fewer 
parts than suggested. Should planning become aware that 
the intended safety pad is not really tJtere, it c;ait lead to an 
escalating battle between the two organizaJions, 

Frame of Reference 

Fundantental to the use of the statistical safety stock meth- 
ods out-hned in This paper is how one chooses to measure 
demand uncertainty, or hi other words, what is tJte point of 
reference. The two alternative \1ews are (see Fig. 3): 

• Demand uncertainty is the difference between part con- 
sumption in the factory* and plaimed consimiption. 

• Demand uncertainty is the diffeience between real-time 
customer detnaiid and the forecast. 

Consider using part consumption within the factory versus 
build plan as the frame of reference. The function of statisti- 
cal safet>^ stocks here is to provide confidence tiiat material 
is available to stitjport die production plan. A factory with a 
steady-rate liuild plan would carry relatively little safety 
stock because there are only small tltictuations in actual 
part consmtiption. Of course, actual order fulfilltrtent jjerfor- 
mance would depend upon finished goods invent oiy arid the 
ap]>roprialeness of the plait. In tltis en\iroitment, tiie orga- 
nization s SRT objective has no direct beating on the safety^ 
stock calculations. The factors influencing the estimate of 
demand uncertainty attd hence safety stock are fluctuations 
in actual builds from the planneti build, pan yield loss, and 
part use for reasons other than production. 

If the point of refererice calls for measturing demand tmcer- 
ttiinty as the de\'iation between the forec-ast and real-time 
incoming customer orders, safety stock becomes a tool to 
provide sitfftcient material to meet ctistonter demaiuf This 
factory is ttol t*imning steady-state production but rather 
building what is required. Now the SRT objective sht^uld be 
iticluded itt the safety slock calculations since proditction 
does not have to litiikl exactly to real-time detnand if tite 
SRT objective is not zero. From this perspective, statistical 



Variabilitv af Actual ver^ys 
For&cast Orders 



Wv 



Measuring demand variafhri Nere addresses 
the problem a\ how much materia:! should be 
ordered to support the uncertainty of actual 
customer demand about the arder forecast. 



Factorv Production 



ma/Va 



Veriabilitv uf Actual versus 
Planned Part Consumption 



Measuring demand variation here addresses 
tfie problem of how mueh matefjsal shodd be 
ordered to support the production ptan 



Fig. 3. Frames of reference for 
measoring demand uncertainty 
These two measures can be very 
different in a faci^o' dedicated to 
steady build rates accorditig to a 
build plan. In a factoo' ftiietuating 
its production is response to ac- 
tual orders, these nvo measures 
are ttiare alike. 
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safety stocks, projected on-hand inventory, SRX and service 

levels are ail tied together, gi>Tng a picturp of the investments 
netH=?ssai>' lo handle marketplace uncejtaint>' and still acliieve 
order Mfiilment goals. 

In choosing between these two Iranies of reference for the 
definition of demand oncertaint>- it conies do^Ti to an analy- 
sis of factor^' complexity and timing. If Eactoiy cycle times 
;ire relalh ely short so that production is not far removed 
from ciisf omer orders, then demand imcertaintj^ can be mea- 
sufed as real-rime onlers vei^ns forecast Howtner. if ^cl,oi>^ 
cycle times are long so that prmiuction timing is wetl- 
removed from incoming orders, then demand uncertainty' 
would best be measured as part coi^sumption veraus build 
plan, 

SHT in Safety Stock Calculations 

Appendix TV dot inneiu.s the iiiaUieniaticy for incorporating 
SRT objectives into die safet>" stock calculationjj. As has 
been discussed, using the SRT tnathernalics would be appro- 
priate when measiuing demand imcertainty as tjeviations of 
re£il-llme customer orders from forecast. It is critical, how- 
ever, that we understand how prodiK^tion cycle times affect 
the factory's actual SRT performance. 

As stated in Ap|)eudix IV, if factory cycle titne is considered 
to be zero, tiie SRT niatliemaU<"s ensures that material suffi- 
cient to mat^ customer orders will arrive no later than tlte 
desired number of weeks after the customer's order. Clearly, 
time must be allocated to allow the factoiy to build and test 
the completed product. In this paper, tliis production time is 
no! the cycle time for building one imit but frjr building a 
week's worth of demand. 

Care must be taken when using tlie SRT mathematics. Con- 
sider that the practice of booking customer orders inside the 
SKT window will place demands r)n material earlier than 
expend (^tl from the mathernatic^d model given in ^i|)])endix IV. 
In practice, one sliotild bv conser\^a!ive and use t^eriiaps no 
rni^re iUmx half of the stated SRT as input to the safety stock 
ttiocieh 

Part versus Product Service Level 

The statistical juathematics behind the safety stock calcula- 
tions are actually ensiuing a service level for parts availability 
and not for completed ])roduct availalniity. This is true r(^ 
gardless of whether lite chosen frame of reference for m€*a- 
suring demand uncertainty' is part -level consimtption or 
product-level ortlers. Since productioti needs a complete set 
of parts to l>uild the pnulut t the question arises as to what 
tJie appropriate p^ul ser%ice level should be to support the 
organizatioEi's product service level goals. LInJortimately, 
there is not a simple aigebraic solution to this problem. 

The exact answer is subject to the interdeper*fiencies aiTKjng 
the probabilities of sUK*king out of any of the individual parts 
in tl^e bill of materials. If we assume that the probabilities of 
stocking out of different jjaits arc* statistically indepentlent, 
then the sittiation looks hieak indeed. F'or exarn|>k.\ if we 
have a 9^l^^» chancre of ha\ing eac^h of 100 ptuis needed to 
build a fiiMshetl product, itulepenflence would sugge.st only a 
0.i«j'*^" - :U^^m cUmve of liaving ail the pans. {'U^arly the 
rluuice of SI IK' king out of one part, is not totally indepemlent 
of stocking oui of another. For example. If ctLslomer demand 
is below phuv tht re is k*HH chance of stocking out of any of 



the parts rcKjuired. Just as clearly, there is not total depen- 
dence among parts. One supplier may be laie on delivery. 
causing a stock<iut on one part number while there are ade- 
quate supplies of other parts on the bill of materials. In the 
example mentioned, the trutli al)Out product service level 
lies between the two extremes, that is, somewhere between 

As an operationtU rule of thiunt>, individual fiart service levels 
should be kept at Jrli^i or pieaier Of course, the procurement 
organization may choose lo ntn ineJspensive parts at a 99.9% 
or even higher ^r\ice level so as never to run out. Then the 
service level on expensive parts can be lowered such that 
the factory gets the highest return on its in\^entorv dollar. 
For example, a factor^' may run a critical, expensi\ e part at 
a 95% service level while mauitainuig a 99.9*Hj service level 
on cheaper components to achieve a product level goal of a 
95% service level to the SRT objective. 

Parts Common to Multiple Products 

In the problem formulation section it was assmned that we 
were dealing with a part uniijue lo a single product and tised 
only once to build that product. First, recognize that the 
situation in which a part is unique to a single prorluci, but 
happens to be itsed more th^ui once lo build the i>roduct» is 
trivial If the product uses a part k tiitTes then the forecasted 
part denuuid is simply k times the forecast for the product. 
Similarly^ the stmtdariJ deviation of the forecast error for tlie 
part is simply k times the standard devtation of the forecast 
error for the product. 

The more interesting situation arises when a part is common 
to nmltiple products. We will look at two alternative ap~ 
proaches to handling ronuru>n parts, the second methr^d 
being sujterior tu the first. In tJie fust approach, we win as- 
simie I hat the forecasting ern>rs !"or the products using tlie 
connnon part are independent of one another. Sint;e the 
foial forecasting error for the part can be written as the sum 
of the forecastitig errors foi' ea<'h of ihe products using the 
part, the standard deviation of the part forecasting uncer- 
tainty can be easily determined. 

t'ofisider apart used in j products and used kj titnes in 
product i, wtiere i = 1, 2, .„, j. Un DE represent the forecast- 
ing or deniand error Tlien: 

DEjj3,n = l<ll^^^prfitlmrt + M^EprodiK-t.2 + l^aDEprijductil 
+ ... + kjDEprfkriiirtj 

^DEpart ^ l^l'^DEproriiK^ll '^ '^S^DEproriiifl2 

+ l^3«DEprt>rtmt-1 + - + ltftJE)Eprc«iuctJ' 

The big problem witii tliis approach is the assumption of 
itidepeuflence of fiirecastjng errors antong idl thc^ products 
using tlie part. If, for example, when one product is over its 
forecast there is a tendency for one or more of the others to 
be over their foreca*^ts. the variance calculated as given here 
will underestimate the tnte variability in pari, demand micer- 
taitny. 

Thes(*ciind approMCh to estimaling forecastitig imceilainty 
for conunon paits is to explode pi'otluct -level forecasts into 
I >art'level forecasts and product-level customer demand into 
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pim-level cienumd aiid measure the clf inaiicj uncertainty 
directly at the part level. For a part comnit^n to j pioducts 
we siraply measure the forecast error once as tiie dilTerence 
between the pait forecast and actual pad fieri laud instead of 
measuiing tln:^ forecast errors for tJie individual products 
atid algebraically ccjrnbining then^ as liefore. Any covariances 
between protiuct forecasting uncertaint ie.s will he picked up 
in the direct measurement of the pait- level forecasting enors. 
Clearly, tjiis is llie preferred approach U> estimating part 
demand unceil^iinly since it avoids making the assmnption 
of forecast error hi dependence aiuong products using the 
part. 

Estimation of Demand and Part Delivery Uncertainty 

The whole aiJproach to safety stocks and invenloiy manage- 
ment outlined here is dependent upon t\w basic premise 
beliind any statistical saiuplhig theory — namely that future 
events can be jnodeled by a sample of past events. Futujp 
demand uncertaitvly is assumed to i>ehave like past demajid 
uncertainty. Fuliue delivery uneertaluty is assumed to be- 
have hke the supplier's liistorical track record. This raises 
two issues when estimating tiie critical injmts to the safety 
stock equations: robust estimatioJi iiird liusiness Judgment. 
Both of tliese issues are extremely dependent upon die 
chosen frame of refen^nce, that is, whether we are measuring 
real-time customer denumd or pait-level consumption on 
tlie factory floor. 

From a sarnple size perspective we would hke to have as 
much tiata as possible to estimate l>ol.li tieniimd and delivery 
uncertauity. However, in a rapidly changing business climate 
we may distrust data older than, say, six months or so. If I am 
measuring demand nncertahity as the deviations between 
real-time^ customer orders and the forecast, do I want to 
llller certain events so they do not miluenc:e the standard 
deviation of demand micertauUy and hence safety stocks? It 
may be good busmess practice not tf j allow big deals to in- 
flate tJre s tan c lard deviation of dem^UKl uncertauity if those 
ciistomeis are wilting to negotiate SRT. In stiitistical Jargon, 
we want our estimates gouig into tlie safety stock equation 
to be robust to outliers. Naturally if the demand uncertainty 
is measitred as part consinn[>tion on the factory^ floor versus 
jjlaimed consumption, data filtenjig is not an issue. It is pos- 
sible tliat an unusual event affecting parts dehvery from a 
suppher may be best filtered from the f lata so that the factory 
is not holding inventorj^^ to guaicl against supply variabihty 
that is artificially inflated. 

A common situat ion is the introduction of a new product. 
Suppose the chosen poirn of reference is Ji^eastmng demand 
uncertamty as real-time customer orders versus forecast. 
How do we manage a new product introduction? A viahle 
option is to use coUective business judgment to set tJie de- 
mand uncertainty even though there is teclmically a sample 
size of zero befoi e introduction. Prior product introductions 
or a stated business objective of being able to handle 
demand falling within ± A of the plan during the early s^des 
n^onths can be used to estabhsh ssfety stocks. In fact^ Oie 
organization can compare the inventory costs associated 
with ciifl'erent assumptions about the natiu'e of the demand 
voiatihly. Estimates of average inventory investment versus 
asstuned demand uncertainty obtaitied frort^ the statistical 
models can helj) the business tean; select an introduction 
strategy* 



Effect of Minimum Buy Quantities and Dei^iired 
Delivery Intervals 

In most cases, there are constrautts on the order sizes we 
place to our suppliers, such that replenishment orders are 
not exactly the (itlTerence between the tlieoretjcal order-up- 
to level and the inventory position. These constraints may 
be driven by the suj}plier in the form of mininnim buy (quan- 
tities or ourselves in the form of economic cjider quantities 
or desirett delivery f resiliencies. The net effec t of all such 
constraints on order sizes is t^ reduce the periods of expo- 
sure to stoek-outs. 

For example, suppose the fact.oiy's plans predict needing 
100 units of some part per week. Further suppose that the 
oniering constraint Ls that w^e order 1000 units at a time de- 
termined by either the su]jpliers nUtiimum or our economic 
order quantity. Tliis order quantity represents ten weeks of 
anticipated demand. Once the shipment of parts arrives 
from tlie supplier, there is virt ually no chance of stocking 
out for several weeks until just before the turival of the next 
shipment. Given this observ^ition we see that safety stock 
requirements actually decrease as purchase quantity con- 
straints increase (see Appendix V). 

Although safety stocks decrease, average on-hand inventory 
and the standard deviation of on-hand inventory both 
increase. See Appendbc III for tV^muila derivations of the 
avera|*e and the standard deviation of on-hand inventory. 

EfTect of Review Period 

Analysis of the equation for the standard deviation of demarid 
micertainty given above shows tJiat as the review t>eriod R 
increases, o^ increases, thereby driving up safety stock This 
makes sense because the safety stock is there to provide the 
tlesireti confidence of making it through K weeks without a 
stock-out. However, note that tlie service level metric itself 
is changing. For R= I, the service level gives the probability 
of making it through each week witliout a stock-oiit. For 
R = 2, the service level gives the prohability of making it 
tlirough two weeks, for R = 3, three weeks, and so on. hv 
creasing review period t herefot e has an effect siniilm- to that 
of mininmm buy quantiries. When operating at longer review 
periods, purchase quantities to tiie supjilier are larger, since 
we are procuring to cov^er R weeks of future demanc! and 
not just one week of futtu-e demmid. To keep the average 
w eekly service level at the desired goal, safety stock would 
actually have to be throttled back as the review^ period in- 
creases because of less frequent periods of exposure. 

Service Level Metric 

Tliroughout this paper, service level has been defmed as the 
probability of not stocking out over a period of tune, usually 
on a weekly basis. There is anotlier commonly used sen ice 
level metric called the I hie itPmjW ntle (LIFR). With lite 
LIFR tlie issue is not whedier stock-outs occur but rather 
w^hether there is at least the desured percentage of the re- 
quired items avaJlablen For example, suppose in a week of 
factory production, demand for apart is 100 units bur tliere 
are only 95 available. Measured in terms of LIFR, the service 
level is 95%. 

Pioponents of LIFR aigue that the metric gives appropriate 
credit for having at least some of what is required, w^hereas 
the probability of stock-out metric counts a week in which 



32 Ff:bruai:j' 1 9flT He wl ett-Pac kar<i J oum al 



)Copr. 1949-1998 Hewlett-Packard Co. 



there was 95% of the required qiianiiiy of a particular part as 
a stock-out 

When ralriilating safet>' stocks to a LIFE metric ratlier than 
multipljing tlie standard deviation of demand over the lead 
time plus the review period by a standard normal %^ue, 
soive for k in the foUouIng approximation formula:- 



U-r 



UFR 



goaJ 



= 1 



Ox 



,t-t)ir^-1.10k-O,371<^'l 



where hd is the average weekly demand. Then the safety 

stock is kox- 

Inventory versus Service Level Exchange Curves 

A useful graphical out|>ut fi orii the statistical iii\ entoiy 
mathentatfcs is ihe inventory \^ersus service le\"el exchaitge 
cui've as showai in Fig. 4. 

Such ^ra]:jlis dei uonstrate tlte nonlinear relationship betw een 
increasing inventory and service level given the constraints 
on the factor>". The cur\^e represents the opeialing objective, 
(.folmson and Da\is^^ refer to this curv^e as the '^efftcient 
frontier." ) By com]3aring historical inventory* and semce 
levels to the peiformance levels possible a^ij indicated in 
Fig, 4, a factory can gauge how much room il has for im- 
pro\^ement. In addition, procurement can detennine where 
oti the cLtr\^c they shoidd be operatmg based upon their cost 
r^jr expedilitig orders. As <^an be seen in Fig. 4. a factory- 
ojjeratii^g in the 90% Ji^rvlce level range would get a lot of 
leverage front mventory money invested to move them to 
95% seivice. However, mo\-lng from 95% to 99% service level 
requirt«> more money artd mo%Titg from 99% to 99.9% requires 
more yet. By compiiriu^ the cost (find success rate) of expe- 
diting piirt.s to avoid stock-oiils with ihe cost of holdmg 
m\ ciiiorTp^ the orgtUiization caji deterntute the most <'ost- 
effective Di>erating point. 

Order Aging Curves 

Another tiseful graphical out|)ut is the order agitig curve, 
Ttiis vuTve in a sense tells the re.st of the story abont materi^il 
availability to meet the SRT and sendee level objectives. 
More specifically the^ curve demonstrates what type of ser- 
vice can be exijected for SRTs shorter than the objective 
and how loitg customers can be t^xpected to wait when you 
are tinahle to nteet yottr SRT t>bjective. Fig. 5 shows a family 
of orfier agijig curvps, each corresponding to a ceHain .safety 




90 92.5 95 

Semcetevel {%\ 

Fig. 4. Average invetitory ils a fujK^lirjji cf sen^ice loveL 



99.3 



5 




SRT Goal = 

SRT Goal = t Weeii 

■ SRT Goa\ = 2 Weeks 

— ^— ^ St!TGoal = 3Wwks 
-«>^— SATGaal-4Wfieks 



2 3 4 5 6 

SRtrWteks) 

Fig* 5* (Irder aging curves for ctiffering SRT (supplier response 
Vmw) goals. 

stock value detemiined by the stated SRT goal, ^^'e see, for 
example, that a factory hokhng safety stocks to support a 
99% service level on a two- week SHT goal could, in fact, 
support a one- week SRT v^itJt a service level better titan 90%. 
That same factor^' will ahitost sin-ely itave aU orders filled no 
later tliait four weeks from receipt of customer order 

Theorj^ versus Practice 

Iltimately. the actual perfomiance the lactory experiences 
in the key ntetrics of service level to the SRT objectives and 
average on-harttl nuentoty will depei\d upon whether the 
supply chaiti [jerforms according to Lite inputs provided to 
the statisticaJ model All of the estimates are predicrat^ed 
upon the fotme supply chain paratnelers Huctuating withiti 
the estitnated botmdaries. As tlepicled iti Fig. 6, we have 
btiilt up a set of assimiptions about t!ie nature of the various 
unceilainties within otjr supply chain. If one or more of 
these buikUug blocks tj roves to be inaccurate, the factory 
will realise neither the seivice level nor the mventorj' 
jirtijected 
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Fig* 6. Supply rhain inputs. The tU;curacy of tlip cistimalc^s (if 
sinice level and oti-hatid kiventdrj' are cJejietKient on tin? VtiUdlty 
rjf tl le inputs. 
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Appendix I: Derivation of the Standard Deviation of Demand Given an R-Weelt 
Review Period 



Hence. 
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L+H 



i=1 i = l 
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^ ^ E(o^] + v(Pl.,r(L+R1) 



We estimate ax by: 



where: t = average lead time from supplier of this part 
R = review period 

Sp^ = variance of the difference between the weekly plan 
and the actual demand 



?i_+^^ average of the plan over L + R weeks 

variance of the difference between the date requested 
and the date received. 



i, 



^ (HL + f\}ai + ?U^ul 



Appendix II; The Expected Value and Variance of On-Hand Inventory when there 
Are no Restrictions on Minimum Buy Quantities 



EiU+R E[t] 

E(l)^ X P| + SS-Xp.-E(Cs). 

!=1 i-1 



let: I = On-hand physical inventory 
S = Order-up-tD level 
Y = Amount of part consumed in first L weeks of the (t + Rl-week t + R 

cycle We wHI consider C3 to be uniformly distributed between and V Dj, 

Cs = Cycle stock = stock consumption to date during the R-week t=t+i 

portion of the (t + R)-week cycle Thus,, 

SS = Safety stock 



I = S - Y - C. 



E(l) = e( X P. + SS J - £( ^ D, J ^ E(Cs 



EJU + fl E[tl E|L) + R 

m^ X p, + ss- vp,-i V p, 

1=1 \ = \ i-HU + l 

E[t] + R np 

E(I1-SS + ^ X P, -SS+^. 
i-qt)+i 

The variance of I is derived as follows. 
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VIH = VtSI + VIY) + V(Cs) 

Bren thoii^ the Pfare not all fixed, and hence S changes every R weeks. 
S is still a constant with respeci to the ifTventory m$uh duriog the lasi ^ 
weeks of every (L + Rhweefc cycle Hence. ViS) = 



E(v(Cs|DL^^DL^^,..D,^H)) 



= E 



VIII = o + v( Vd, j +V(Cs) 

V(l) ^ (oK + of Pf ) -H V(Cs) ' 
V[Cs) = Efv(Cs|Ou^DL^^.--,Dt^fl)] 
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tz 



^ _Lt/f^2 
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where 6 = 0^+1 + Di_^2 + ■■ +Oi-^R 
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e(Cs|0l4-,,Dl+2 Dl+r) = 



£(v(Cs|Dl^,,Dl+2 Dl+r))=^ Ro|+( V pj 



= ~V({P[.+ , + Bl-h) + (Pl + 2 + Sl+z) + ... + (Pl + A + Bl+h)) 



V(Cs} = 1^ 
Hence, 
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v(Cs|Dl+i.Dl + 2 Dl + r) = 



1? 



where Ples the average of the plan over the L-week period immediately 
before the R-week period in question. 



Appendix III: Tlie Expected Value and Variance of On-Hand Inventory when there 
Are Res trie lions on Miiumnm Buy Quantities 



Here we assume that restrictions on the size of orders placed to the 
supplier prevent procurement from ordering exactly the difference be- 
tween the order-up-to level and the inventory position. The restriction in 
order si?e might be the result of a minimum buy size constraint placed by 
the supplier, a constraint that the order must be an integer multiple of a 
specified quantity, or the purchaser's desire that deliveries come at some 
delivery interval greater than weekly. 

Let Min = minimum order size constraint 
Mult =^ multiple order size constraint 
D I - desj red de I i very i n terva 1 c onstra int 

Then the order size decision rule is given by: 

New order size = M = k x Mult. 

vyher'e k is the smallest integer such that: 

1 M ^ Order-up'ta Level — Inventory Position 

2 M >Min 

3 M > Dl X Average Weekly Demand. 

Finally we assume that the order is placed for the entire order quantity 
to be delivered L weeks later, that is. the order is not partitioned into 
pieces with separate delivery dates 

Let: 1 = On-hand physical inventory 
S - Order^up-to level 

Y = Amaunt of part consumed m first L weeks of the (L + R^week 
cycle 

Cs = Cycle stock = stock consumption to date during the R-week 
portian of the (L + R)"week cycle 



SS = Safety stock 
M = Order quantity 

A = Increment above the order-up-to tevel S that the inventorv 
position reaches as 3 result of having to order a quantity M, 

I = IS + Al - Y - Cs 

Ed) = £(S) + E{A] ^ m - E(Csl 



Ed) 



.g,.ss) 



+ E(A)-XP'-^ 1 P' 



L + H 

1 



L + fl 



011 = SS + E(A1 + I X Pi 



To determine E(Al note that rather than buying strictly an amount equal 
to (S - Inventory Position] we buy a quantity M Therefore, the differ- 
ence between what would be ordered without minimums and what is 
ordered with minimums varies between and M — 1 We will assume 
that this difference is uniformly distnbuted withm this range. Thus: 



E(l) s SS + 



M 



2 2 



L + R 



1^^ 
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The derivation of the variance of I is as follovvs. 



V(l) = V(S) + V(A) + V|Y) + V(CsJ 



VIII = + V[AI + V £D| j + V(Cs) 



V(l) = VIA) + al)ii + o^pf + 1 



V(ll . i^ + a^,, + alPl H- ^ 






H 



H 



where P[i3 the average of the plan over the L-w^ek period immedfately 

before the R-week period in question. 



Appendix IV: Incorporating SRT (Supplier Response Hme) into the Safety Stock 
Calculations 



A weekly review period is assurrred. 

Let: X — actual amount of demand for an arbitrary part in L + 1 weeks. 

S = Order-up4o level = y P, + Zi^^ofx- 



X fs assumed to be normally distributed with mean (L+ 1 )[.id and vari- 
ance a^(L -K t) + af|x^. 

Then ProbjX < S| - 1 - a, so T — a is the service level 

Ore-Week SRT 

The probability that some" demand is actually filled the week following 
its arrival is the probability that the order-up-io level over L + 1 weeks 
covers demand incurred over just L weeks. 

Let X* be the amount of demand in L weeks. X* is normally distributed 
with mean LpQ and variance a^L + ol^q. 

If SSt denotes the appropriate safety stock for a one-we&k SBT the 

corresponding order-up-to level for a one-week SRT goal is St == 

L+l 

^ Pj + SS]. However, 



Prob(X^ ^ Si) ^ Prob 
This implies that 



Z < 



Sf - LiiQ 



Jail + al^l^ 



= 1 -a 



h^ = 






The order-up-to-fevel will still be calculated by our in-house procurement 

1+1 
system, POPLAN. as Si ^ V P, + SSi, so we now have two expres- 

sions for Si- Assuming that ^o = Pl + i- 



Si = (L + 1)^D + SSi = Zi_a^/a^L + ofp^ + Lliq 



SSi = Zi^yagL + alyil + Ljip - (L + D^D 



SSi -Zi-^/agL + a^^ig- 



\^U' 



L+l 



By using an order-up-to level of V Pj + SS i . over L -h 1 weeks we will 

1 = 1 
bring in enough material to cover the demand incurred in L weeks a 
percentage of the time equal to (1 - a) x 10D%_ 

Two-Week SRT 

The probability that some demand is actually filled two weeks after its 
arrival is The probability that the order-up-to level over L + 1 weeks cov- 
ers demand over just L - t weeks. 

LeiX** denote the amount of demand m L - 1 weeks and let S2 denote 
the order-up'to level appropriate for a two-week SRT, X** is normally 
distributed with mean (L - 1 liio snd variance ap(L — 1) + al\il. 



Proh(X** < S2) = Proh 
This implies that 



2 < 



S2~IL-11^D 



JaUi-W + aful^ 



= 1 - a 



Zmi = 






Sz = I^^uJol{l - 1) + ol^l + (L - IHiQ. 
Since the PQPLAN system will calculate order-up-to level as S2 = 
y Pi + SS2/we have two expressions for the order-up-to level 82 

i=1 



Sj = (L + Dpe + SS? = Zi_, /og(L - 1) -H al4 + (L - IVo 



SSz = Zw. /°d1L - 1> + ol^ii + |L - Ij^ip - [L + IJpc 



SS2 = h^^'ulil - 1) + qI\iI - liiQ. 



GerteraE Case 

In general the safety stock required for a given SRT goal is given by: 



SS = 2i^ /ag(L + 1 - SRT) + a^fig - (SRTj^o- 
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However this equation only ensures amval of material from the syppiier 
no teter tf^n the SRT it does not guar^itee that ^ faciory will actually 
have ihB final prttduct built and f^dy for shipment to the custDmer no 
later itian the SRT Produaion cycle time must be incorporated into the 
equation to make ifie result useful in setting safety stocks id support 
product SRT objectives 

Lei Tg denote the production cycle time required to build a week s worth 
of expected demand Then 



In all cases, forecast en'or is measureif as 
ouile 1 Mr«ftks before. 



Parti Orilef 
^laeed t0 Vendor 



l^/foehs 



— Cusd:iHn€f's Order Arrives 

— PrcKJuirlicHi Begins^ 
Build -Pfodiicl Ships 
Time 



ss 



- Zi-a JoUl + 1 -- SBT "h Tb) + olvil - (SRT - Tb)|il: 

Consid&r the three cases exfiibited in fig IJf v^/e let build time be tv^ra 
weeks m all three cases m4 let SRT be 4, 2, and wee^s, respectively. 
then we have the following results. 



ia\ 



Parts ird^r 
•- Placed to Vendtir 



Case A. SS = h^, JalU + 1 - 4 + 2( + ofug - (4 - 2)ud. 



LWeelts 



SRT 



DinSiHners Onler Arrives and 
P Production Begins Immediaielv 

Build r Pfw*"crShips 
Tinte 



m 



l^SRT-H 



Case B. SS = l^^ ./og(L + 1 - 2 + 2) + of^^ - (2 - 2}|1d. 



Case C. SS = Zi^ JaUl + 1 - + 2j + of^^ - (0 - 2)|io. 



Parts Order 
Placed tfl Vendor 



L Weeks 



Produciton Begins 



Build 
Time 



Cystomer s Older Arrives and 
- Product Sfiips Immediatelv 



(cj 



SBT=0 



Fig, 1, Produdion cycles for different SRT goals. \a\ Case A. SRT — 4 weeks 
[b) Case B: SRT - 2 weeks, (c) Case C : SRT ^ weeks. 



Appendix V: Derating the Service Level to Account for Reduced Periods of 
Exposure to Stock-outs as a Result of Minimum Buy or Economic Order Quantities 



When ordering parts Irorn a supplier under either mrnimjm or economic 
order size restrictions, with each arrival of a shipment from the supplier 
we would expect the service level to jump to 100% arrd then decay as 
indtcated in Fig. 1 

Since there is realistically only exposure to a stock-out as we approach 

the arrticipated arrival of tfie next shipment from the supplier, we can 
afford to run a higher risk of stocking out during these tinies and still 
achieve an overall weekly service level objective. The larger the pur- 
chase quantity constraints, the less frequent the periods of exposure 
and, therefore, the lower the service level we can afford at the end of 
the decay cycle depicted in Fig. 1. 



100 




Given that purchase quantity constraints dictate minimum order quanti- 
ties equivalent to W weeks of expected demand, the objective is to 
equalize the service level achieved on all parts regardless of the order 
frequencies This will be accomplished by basing the service level on a 
weekly equivalence. Given a weekly review period, a weekly desired 
delivery interval, and no constramts an order sizes, the probal^illty of 
making it through W weeks without a stock -out is given by: 

(Weekly Service Level)^, 

Therefore, if we are ordering in quantities equivalent to W weeks of 
expected demand, the service level used to datemiine safety stock 
should be derated to: 

(Weekly Service Level Objective)^, 

Example: We will order in quantities equivalent to four weeks of supply, 
and we desire a weekly equivalent service level of 99%, 

Derated Service Level ^ (0.991'^ = 0.96 



WMks 

Fig, 1. The service level jumps to 100% each time a shipmint of p^rts arrives 
grid thirt gradually decays 
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Appendix VI: Estimating Weekly Demand Uncertainty from Monthly Data 



The standard deviation of demand uncertainly used in the safety stock 
equaiion is a measure of the weekly uncenamVi of real demand about 
the plan. Ideally, data should be taken on a weekly basis so that this 
statistic can be estimated directly as the sample standard deviation of 
the diffefence between the weekly plan and the actual demand. Howev- 
er, it is faidy common that such data is not readily avaiJabJe. Typtcaily, 
the factory has data aggregated at the monthly level for comparing plans 
to actual demand. An estimate of weekly demand uncertainty can still be 
obtained if we make a simplifying assumption about the interdepen- 
dence of the demand uncertainty from weak to week. 

Assumption: Demand uncertamties are independent from week to week 
withtn a month, that is, knowing the difference between the actual 



demand and the plan for this week does not give you any information for 
predicting the difference between the actual demand and the plan next 
week. If this is the case, then 



^^^ weekly 



= 13a; 



or 



monthly 



^^weekly ~ ^To^rnontWy 



Appendix VII: Adjusting Safety Stock to Account for Yield Loss 



Procurement may wish to account for part yield loss in some situations. 

Here we use yield loss in a general sense to include additional part con- 
sumption either because of literal losses resulting from failures or dam- 
age or because of addittonpl use of the part for unplanned reasons. 

Let V| denote the weekly yield of an arbitrary part.. We will assume that 
Yf is distributed according to the binomial distribution. 

The actual demand on a part per week is given by: 



for week i = 1,2.3, 



-(^) 



. The expected value uf the actual demand is: 



^- J.cov(D„Y,)4-^VlY,l 



We will assume that yield loss each week is not correlated with the 
demand each week. Then: 



VjYj 



\iyl1 - ^ly) Uyd - f^v) \^P - N 



L^n/f^v 



^D 



where n is the average number of parts used per week and we have 
approximated n by the average weekly demand divfded by the average 

yield. Thus, 



m\ 



When ^Y ^ 50%- the term — ^^ — is less than or equal to one and 

has little effect on expected demand. Therefore: 




EjD') - 



t^y 



The variance of the actual demand is 






As before, we will assume that yield luss is not correiated with ttie de- 
mand each week: 



VIDI) 






Again we will approximate ay by 



H?(1 



I^yI 



m 



WDM ~/^*c.\Y"D , i-hy\ °^ 



M'^ - i^v) 



^\ 



Therefore, by adjusting the expected weekly average demand by dividing 
iby the average yield and adj Listing the variance of the weekly demand 
uncertainty as indicated above, we can obtain approximate values for 
safety slock, average expected on-hand inventory, and the standard 
deviation of on-hand inventory using the results obtained earlier in this 
paper. 

However while we have adjusted the expected weekly demand by the 
yield loss, our in-house system. POPLAN. will not. Therefore, we must 
pass the impact of the yield adjustment to POPIAN via the safety stock 
parameter. 

Let SS' denote the safety stock obtained when using the yietd-adjusted 
average demand and standard deviation of demand uncertainty as de- 
rived here. The objective is to pass a safety stock value to POPLAN that 
results in the appropriate order-up-to level 

The safety stock to pass to POPLAN is given by: 



SS*- 



(L -h R) + SS' 



^DlL + F). 



In words, calculate the safety stock and the order-up-to tevel using the 
yield-adjusted average weekly demand and the yield-adjusted standard 
deviation of weekly demand uncertainty, then subtract the product of the 
average weekly demand without yield adjustment and L + R. 

Reference 

T A,M. Mood, F.A. Graybill. and D.C. Boes, Intfoduction to the Theory of 
Statistks, Third Edftion. McGraw-Hill, 1974. p. 181, theorem 4. 
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A New Family of Sensors for Pulse 
Oximetry 



This new family of reusable sensors for noninvasive arteriat oxygen 
saturation measurements is designed to cover all application areas. 
It consists of four sensors: adult, pediatric, neonatal and ear clip. 



by Siegfried Kastle, Friedemann NoDer» Siegfried Falk, .\nton Bakta, Eberhard Mayer^ 
and Dietmar JVliUer 



Since tiie early 1980s, when pulse oximetTy was introduced, 
this noninvasive method of monitoring the arterial oxj'gen 
saturation level in a patient s blood (SpO^) hjis become a 
srandai'd method in the clinical environment because of its 
simple application and the high value of the information it 
gives nurses and doctors. It is as common in patient ntoni- 
toring lo measure the oxygen level in the hloofl as it is to 
monitor heart activity' witli the ECG. In some appUtatlon 
areas, like anestjiesia m a surgical procedure, it is mandatory 
for doctors to measure this vital jDarameter. Its importance 
is ob\ious considering that a human being cannot sm-vive 
more than five minutes without ox:y'gen supply to the brain. 

Before the advent of pulse oximetiyj the common practice 
WBS to draw blood from patients and analyze the samples at 
reguJar interv^als — several times a day, or ev^en several times 
an hour— using large hospital laboratory equipment. These 
in-vitro analysis instnmients were either blood gas analyzers 
or hemoximeters. Blood gas analyzers determine the partial 
pressure of ox>'gen in the 1)1 ood (pOi^J by means of chemicaJ 
sensors. Hemoximeters wcjrk on spectrometric principles 
and directly meitsure the nitio of tlie oxygenated hemogl<3bin 
to the lotaJ hemoglobin in a sample of blood (SaO^J. 

HP pioneered the first Ln-vivo lechnology t.o measure a pa~ 
tienfs oxygen saturation level without the need of drawing 
blood samples in 1976 with tjie HP 47201A eight-wavelength 



ear oximeter^ An earprobe was coupled through a fiber- 
optic cable to the oximeter mainframe, which contained the 
iight source (a tungsten -iodine lamp juid interference filters 
for wavelengiJ^ selection) and receivers. This instnunent 
served as a "gold standard" for oximetry for a long time 
and was even used to verify the accuracy of the first pulse 
oximeters in clinical studies. 

The real breakthrough came in the 1980s with a new genera- 
tion of insiniments and sensors tiiat were smaller in size, 
easier to llsc, and lower it) cost. These new iiLStruments used 
a slighUy different principle from the older, purely empirical 
multi wavelength tecluiologj^. bistead of using constant ab^ 
sorbance values at eight diffejent spectral lines meiisured 
tlirough the earlobe, the new pulse oximeters made use of 
Oie pulsatile component oi' mleriid blood generated by the 
heartbeat at only two spectral lines. The necessary !igl\t was 
easily generated by tv^o light-emit ting diodes (LEDs) with 
controlled wavelengths. Small LEDs and phot odioiies made 
it possible to mount the optic al t:on)ponenfs directly on the 
sensor applied to the pal ienl, avoiding the necesstty of 
clumsy fiber-*3ptic bundles. 

Instruments and SensoriB 

The first pulse oximeters were standalone products. HP 
offered its firs! pulse oxinietry devices as additional measun^ 
ments for mi e. listing monitoiing product, ttie lU^ 78^352/54 
family in 11.KS8. A year later the Boblingen Medical !)ivisJon 
introduced a new niodular padeni nujnitor, the Component 




Fig. 1- The HP MlfJ^UA SpU^ front -enci module for Uw IIP 
(Jumponen! Moniioring System. 



Fig. 2. 7\ji 111' CodeMEister defibnlkilur with i^pOj, channet 
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Fig, 3. The SpOs chamel in an HP XM Series fetal monitor 
monitors the mother during delivery. 

Monitoring System r for which a pulse oximeter module was 
also available, the IIP M1020A (Fig. 1). The application was 
hmited to adults and the only sensor available was the HP 
M1190A, mi advanced design at that time. This sensor is the 
ancestor of the new seasor family presented in this pap en 

Two years later, the HP 78834 neonatal monitor extended 
SpO-j measurement to newborn applications. Third-party 
sensors were used. 

Today, all typical monitoring application areas have discov- 
ered pulse oximetry: intensive care, operating rooms, emer- 
gency, patient transport, general wards, birth and dehveiy, 
and neonatal care. HP monitors serving these arcEis include 
the IIP M1025A anesthetic gas monitor (1990), the HP Com- 
ponent Transport Monitor (1992), Sp02 options for the HP 
M1722A and M172;3A CodeMaster XL defibrillators (1994, 
Fig. 2), and recently the HP M1205A OmniCare monitor and 
the HP l:350B mateniaJ SpO^ option for the HP XM Series 
fetal monitors (Fig. 3). 

New Sp02 Sensor Family 

A new family of reusable HP pulse oximetry sensors is now 
available (Fig. 4). Lower in cost than previous reusable sen- 
sors and easier to use than adhesive disposable sensors, the 
new HP Sp02 sensor family is hardware compatible with 




Fig. 5, The basic components of an Sp02 pulse oximeter sensor 
are two LEDs with different wavelengths as light sources and a 
photodiode as receiver. 

HP's installed base of pulse oximeti^ front ends. An upgrade 
to the software is necessary to update the calibration con- 
stants in the instrument algorithims to match the optical 
characteristics of the new sensors, such as spectra and in- 
tensity. The new sensor family covers all apphcation areas 
and coitsists of the HP M119iA (aduh, new wavelength), 
MU92A (pediatric), M1193A (neonatal), and Mil94A (clip), 

Sp02 Basic Measurement Principles 

The breaktlirough from oximetry to pulse oximetry came 
with the new LED teclmology m 1982 to 1985. LED light 
sources are very small and easy to drive, and hav^e the great 
advantage that they can be mounted withm the sensor to- 
gether with a photodiode receiver (Fig. 5). For correct mea- 
siurements at least two LEDs \\ith differeiit wavelengths are 
necessaiy, A suitable combination consists of a red LED 
(650 nm) and an Infrared LED (940 mn). The red LED's wave- 
lengtJi has to be in a rtarrow range, which is not normally 
possible with standard commercially available LEDs, One 




Fig. 4, The newfemly of reus- 
able HP pulse oximetry (SpO^) 
sensors: (kft to riglit) adult fm- 
ger glove, pediatric finger glove^ 

neonatal foot strap, ear clip. 
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licidem UghL 
Intinsitf = Iq 



Ext = EKiinctfon Codfjciem of Absorber 
c = Conceniraiiond Absorber 



d =TliJck(iess 
v^ Absorber 



f 



Transmitted Light, 
[ntftnsitY = I 



Fig. 6. Idealized model for ihe valiciit>* of the Lambert-Beer ]a»v: 
a monochromatic light sourre, parallel light propagation (no point 
source), and no snatrcring, 

way to overcomo this is to provide in each sensor a calibra- 
tion resistor niatchetl to tlie actuaJ LED wavelengtli. Another 
way is to select only LEDs with a fixed wavelengUi. Tliis 
nierhcKl lje(x)njes practical if the LFi^D wafer production yields 
a narrow wavelei^gth distribution. HP decided oti tills second 
method because the red LEDs could be obtained from the 
HPOiHoelectrtmics Dimion, witich had long expt*rience in 
wafer production ;md was able to maintain a sufficiently 
narrow wavelejigth distribution. 

The front-end hardware apphes a time multiplexed approach 
in which the two LEDs are switched on and off alternately. 
Tlie t Itne phases usvtally consist of a minimum of iJiree: active 
red, active infrared, ajid a dai k phase \\\ wiiich the ambient 
light is measured. There can he more than three phases to 
allows more LEDs to be powered in one nutltiplexing time 
frame or to allow additional dark i^hases. The phases are 
similar in duration. The modtilation frequency (the complete 
frame repetition rate) typically ranges fn>m 2fM) Hz to 2 kllz. 
The frequency spectnttn of such a time muliiplexed signal at 
the receiving pliotoditjde consists of small batids (approxi- 
mately ± 10 Hz) arotind the modulation trequency and its 
harmonics. Depending m\ t he width of the indi\idtial LED 
pulses, the harn\onic frequency content is of significaiit 
amplitude for several tens of harmonic orders. 

For an idealizerl light absorbing model as showi^i in Fig. 6, 
the I^ambei1-Beci' law applies. The intensity I of the Itght 
tranxsmitted is related to the incident Ugltt lo by: 



I = loexpC - Ext. * c ^ d), 



(1) 



where Ext is the extinction coefOcient m\i\ v. is the concen- 
tration of a single light absorber with ihit ktiess (I Ext varies 
as a function of the absorbing substiiiice and the wavelength 
of the hght, Fitrther assumptions for the vdidity of eciuation 1 
are tliat ihe lighl soun e is moticjchrontatic mid has |)aj*allel 



propagation and that the absorber is optically homogeneous 

(no scattering effects). 

Under these assimiptions the model of fig. 6 can be used to 
derive the basic pulse oximetric quantities. Fig. 7 shows a 
simplified mode! for the blood vessel system in tissue. \^lth 
each heartbeaL the % olume of tlie arteries increases before 
the blood is forced inio the capillaries and from there into 
the veins. This change of arterial volimte is the basis for 
pulse oximetiy because it makes it possible to separate the 
arterial blood from all other absorbing substances. 

Assume tliat there are N layers of absorbers and rhal the ith 
absorber layer has concentration Ci, thickness dt, and extinc- 
tion coefficient Ext(iA). Prom equation 1 it follow^s, at dia- 
stole, when there b a maximuni of light intensity: 



In^Q^ = lLED(>^)exp(- £E3a(i,X)CidLl^ 



(2) 



i=l 



At systole, the maximuni of the heartbeat, and uncier the 
assumption that only hemoglobin ^id oxylienioglohin are 
active absorbers in the arterial blood* two additional al>sorb- 
ing parts are added in the exponent of etiuation 2. which 
yields the minimum of light intenshy; 

IminC'^J ~ 
lmaxWexp(- A(t(ExtCHb,/.)[Hl)] + Ext(Hb02,>.)[HbO2])), 

(3) 

where [HbJ is tiie concentration of hemoglobin and [Hb02] 
is the concentration of oxyhemoglobin. Dividing eqviation 2 
by equation 3 aitd taking the logarithm yields the absorption 
of t lie iuteilal blood: 



I LED 



* 



Tissue 



AftflriRl Blood 



^ 



^^. 



id 



Capillaries 



Venous Blood 



d 



V 



Fig. 7. SiiiiplifH^d nwM for I he bloofi v<^<isel systeni. With each 
iioart tipat , Llie arterial radius expatuisi by an amount Ad, wliieh 
yields a light intensity r'hattge from Ijru^c fo liTiiii- 
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Fig. 8. Extinction coefficients for hemoglobin Eb and ojcyhemogtobin 
HbOa as a function of wavelength. A red LED with X = 650 nm gives 
good resolution between HbOa (100% Sp023 and Hb (0% SpO^, 



III 






Ad(Ext(Hb,>w)[Hb] + ExtCHb02, ?i)[Hb02]), 



(4) 

where Ad is the change in the aneriai radius (see ng. 7). 
The definition for the ox>^gen saturation in pulse oxitiieio^ is: 



Sp02 



[HbO^ 



[lib] + [m^Oil^ 



(5) 



With two ligltt sources (LEDs) of different wavelengths Xi 
and ^2 the arlerial expansion Ad can be eliiniiiated by the 
following relation, wliich is calle^l the ratio, jt: 



H = 






(6) 



_ Ext(Hb.X|)(l - Sp02) + Ext(Hb02,/.i)SpOg 
" Ext(Tib,X2)(l - Sp02) + Ext(Hb02,A2)Sp02 

Thus, the oxygen saturation SpO^ is: 

Sp02 = 

PExr[Hh,X:jj - Ext(Hb,?4J 

H(Bxt(Hb,XiJ - ExKHbOj, X2JJ + Ext(Hb02,Xi) - Ext(Ilb,?qV 

For example, with LED wavelengths ly = 650 nm and X2 ^ 
940 nm.the extinction coefScients are (see Fig. 8): 

Ext(Hb,650) = 820 (Mol ■ cm)-i 
Ext(HbO:;,(550) = 100 (Mol ' cm)- ^ 
Ext(Hb,940) - 100 (IMol ■ cni)-i 
Ext(HbO2,940) = 260 CMolcmr^. 

In Fig. 9 the Sp02 is plotted as a fiuiction of the ratio E. The 
Lambert -Beer relation is comparetl mth a calibrated ciiire 
derived from real arterial blood samples from volmiteers 
(see "Volunteer Study for Senso]- Calibration" on page 48). 
The deviations exist because conditions in the real case 
(complicated tissue structure, scatrenng effects, point light 
source, etc/) are different from the Latubert-Beer assump- 
tions. 



Fig. 10 shows the sejisor LED driver circuit and receiver 
cu-cuit. The LEDs are thriven hi sequence at a repetition rate 
of 375 H2 m antiparallel fashion. At the photocUode the 
intensities airive in the sequence red (R), infrared (IRj and 
dark. In the receiver circuit this signal is --^plit into three 
paths: a red path, an uifrared path, and a diirk patli. The 
dark intensity is subtracted from the red and infrared. 

Fig. 11 shows the separated red and infraied patient signals 
with their Ij^^^^ and li^^.^ values caused by arterial pulsation, 
from vvliich the ratio ? can be calculated (equation 6)* 

Ambient Light and Electrical Noise 

hi a clinical environ ment^ the sensor picks up ambient light 
and electromagnetic noise from various sources. The majjor 
source for ambient light is room illumination, typically fluo- 
rescent ceiling lamps, which have broad spectral bands with 
peaks at harmonics of the powei-line frequency, 50 Hz or 
60 Hz. Veiy often, electjiral noise also comes from the power 
line and shows up as hannoiiics of die hue frequency. Other 
w^eli-known sources of large mtcrfermg electrical signals are 
die electros mgery devices used in operating rooms, wliich 
can be very broadband, 

Typical current levels at the sensor photodiode are arotmd 
1 tiA dc with the blood ciurent pulse modulated on the dc 
levels at a modulation depth of typically one percent. It is 
likely that the LED spectra incluiUng the desired signal and 
the optical or electrical noise spectra will overlaii. Any noise 
hues in one of the LED modulation bands will be demodu- 
lated and folded down to the baseband, where they will con- 
tribute to poor signal-to-iioise ratio (S/N), Avery dangerous 
situation for t!ie patient can occur in tlie monitoring of neo- 
nates, w^ho are ol'ten treated with veiy bright l^' lamps for 
biUrubm phototherapy. Neonates give poor SpO^ signals 
because of poor vascular perfusion, so the bright L\' ambient 
light can cause situations in wMch S/N < L A ptjlse oximeter 
is very likely to be misleading in these situations. It cajT 
derive values for pulse rate and oxygen saturation thai are 
wToiig because tlie mput signals are dominated by noise. 

Because interference can lead clinicians to apply incorrect 
care and therapy and cause harm or even death to patients. 
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Fig, S. Theoretical (Lambert -Beer) and real calibration (arteriai 
blood sample s_) cnn^e for the J-IP Ml 190 A adult sensor. The difter- 

Giice is iiiainly caused by scattering effects and noiuileal llgtit 
sources. 
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Fig. 10. (a) Sensor LED driver 
circuit and (b) receiver circuit. 



it. must b^ avoidpci at aJl costs. A major goal for the spnsor 
design was optimum optical aiid electrical shielding. Fig. 12 
shows the pediatric sensor. Its closed housing is designed to 
shield the sensor from interfering ambient light. 

Movement Artifacts 

Because the pulse oxiinet r>^ method relies oti the pulsatile 
part of the absoiption, proi^ably the most frequent cause af 
trouble is movement of the patient. .\ny movement tisually 
causes movemenr of tlie sensor or live tuinjirlerial tissue 
imder the sensor and thereby leads to noise on the signals, 
A design goal for the new sensors w^as to be sniaD and light- 
weiglit and to attach firmly to the patient. The cable was 
made as thin and flexible as possible consistent with the 
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need for robustness, so that it adds little weight and stiff- 
ness, tJtereby helpitig to decouple the sensor from cable 
movements. 

Cable Robustness 

The clinical environment c<in be vety harsh. Sensors fall off 
paliefus- People step on them and t-iirts roll over Iheni, 
C'ables get stiueezed between drawers and racks. The cables 
of niedi<Tal seasors, In partknilar, liave to be exirerttely robust. 
They are moved. l>ent. kinked, and treateri with aggressive 
disinfectants. 

A carefully selected lead composition and the use of non- 
breakable material were goals for the cable constmction. 
A new connector and interconnection concept are used. The 
interconnection is si>lit into iwo paits: a short, thin, at^d 
more fragile cable is used wit h the sensors for low weight 
and minimum mechanical stiffness, while a longer, heavier, 
more robust cable was designed as an interface cable to rJie 
instiimient. 

The connector joining the cables (Fig, 13) is optimized for 
small size. Ioav weight, ^md robustness. Special care was 
taken to provide very high insulation between the pitis and 
to make tlie interconnect junction watertight to avoid leaJc- 
age currents in humid environments like neonatal jnctilm- 
tors. In older designs, saturated water vapor ami sally resi- 
diu^s from infusions or blood on comiectors was a common 
source of problems, JeatUng to erroneous measurement 
resuita. 



Fig. 11. SFvparaied md mid ijifrured patient simm-iI^ vviiti ili* tr Irnm 
and lijjjLx ^iihies caii!5ed by arterial pulsation. 
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Fig, 12, Tite IIP MI 1 92 A pfMliaLric sensor 1ms a tiioseii housitig lo 
.shield it from iiilerfermg ambient light. 



Setting Design Goals 

HP has offered a reii.siible SpO^ sensor since 1988, but in one 
size only: the adiih HP Ml 190A sensor. This sensor is verj^ 
well -accepted, Tlie objective for the new sensor project was 
to extend this sensor technology to a family of sensors cover- 
ing all of the different application areas, so the customer is 
not forced to use a thirtl-party sensor for apphcation reasons. 

Based on experience with the HP M1190A sensor and on 
customer feedback w^e defined the folio wmg objectives; 

• "Must" Objectives 

Reusable sensors only 
o Cost competitive with disposable sensors 
o Clear, nonconfusmg apphcation 
c No bums on skin 

State-of-the-art necrosis factor behavior (niiniinaJ local 

cell damage) 
c No penunibra effect 
- Influence of ESI (electrosurgery interference) as low as in 

HPM1190A 

Backward compatibiJity with HP monitors (hardware) 

• "^Wanr" Objectives 

c Reliability equal to HP M1190A 
c Easy to use 

Comfortable application over long period of time (several 

days) 
c Reliable fbdng mechanism 

c Cleanmg and sierilization by mmiersion in solutions 
c Mechanical ty robust design like HP Ml 190A 



(bl 



Fig. 1 3. 1'l ug and S( jc^ket tonnecto system. 

'' Cable size, lengtlt, flexibility and quality similar to HP 
M1190A; alternatively, trunk cable and sensor cables 
No influence of ambient light (operating room, bihnibin 
therapy, fluorescent hghts) 
Mlninumi motion artifacts 

Backward compatibility with HP monitors (software) 
Compatibility \\ith competitive monitors. 

Reusability was required because HP feels en\iroiimen tally 
responsible for IIP products. Most of the sensors on tJie 
niarket are disposable, which means that they are applied 
only once, after w^hich tliey must be dispose*:! of k\s medical 
waste. Reusable sensors are a small coruribution to protect- 
ing the environment. 

We used the Quality FunctitJU Deplo>Tnent^'^ (QFD) tool for 
de\ elopmg these sensors. The starling point for QFD is tlie 
customer — what does tJie custon\er weuU? The customer 
requirements are weighted according to their relative impor- 
taiice, I he corresponding engineering characteristics are 
listefi, and step by step a matnx is bujlt that provides tlie 
means for interfunctional planning and cotmmmication. 

The three most Important customer attributes we found are: 
Fmictiotiality Minimize physiological effects like skin irrita- 
tion and low ])etf[ision. This means selecting the appropriate 
material and applying the appropriate clamping force. 
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• Performance. Ensure good signal quality'. The most impor- 
tant issue was to select optical components to prmlde good 
iight ixansitdssion. 

• Regulations, The sensors had to meet U.S. FDA require- 
ments and iniemational safet\^ and EMC standards. 

We have had several clinical trials to veril>" that we under- 
stood the customer requirements correctly. At the release of 
the product for manufacturing we checked our solutions 
again to make cenain tliat they are in acconjance with the 
required customer attributes and engineering characteristics- 
We have been shipping the sensors for over half a year mth- 
oiit any customex objections. This makes us fairly confident 
that the sensors meet customer expectations. 
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Design Concept 

The next step after defmtng the project goals was to evolve 
the basic design concept. To reduce waste (e\'en reusable 
parts have to be replaced eventually) we decided that each 
transducer would consist of two parts: an adapter cable to 
be used for all sensors and a sensor cable consisting of con- 
nector, transmitter, receiver, and a special sensor housing 
for the specific application site (finger of a child or small 
adult, foot or hand of a neonate, ear of an adult J, We made 
this split since the lifetime of the adapter cable is longer (we 
estimated thi'ee times longer) than that of the sensor cable, 
which is much lighter in weight to reduce motion artifacts. 
A further advantage of the tw^o-part design is the flexibility^ 
for future products to use the sensor without an adapter 
cable. T\\e design required the development of a new 8-pin 
connector family. 

To minimize the risk, becaiase of the very good customer 
feedbac^k for the existing adtilt sensor, we decided to change 
only the opticaJ elements of the transducer 

The detailed design concept is shown in Fig. 14. Tlie adapter 
cable is a shielded fwisted-pair cable vnth four single conduc- 
tors, a i2-contact male plug on the instrument side, and an 
8-contact female comiector on the sensor side. The sensor 
cable is a shielded twisted pair cable with two conductor 
pairs, an 8-contact m^ile plug on the instrument side, a trans- 
ducer coasisting of transmitter and recdver molded in epoxy, 
and a special sensor housing. 

Housing 

Witli the project goals in mind, the fn^st proposals for the 
sensor housing were designed and prototype tooling was 
ordered to get parts ready for the first application tests. It 
was e^eciaUy necessary to stait witlt application tests as 



Neonatat/AduK 
M113aA 



ClipMl194A 

Fig. 14- Design concept for the new sensor family. 

soon as possible for the neonate sensor, because this sensor 
would cover the biggest area and would be the most sensi- 
tive. The design of the pediatric sensor was more straight- 
forward. It had to be similar to the existing adult sensor. For 
the other two sensors we approved a couple of proposals 
and ordered the prototjpe tooling for those. 

With these samples we went into hospitals and spoke to 
nurses and medical technicians. When their response was 
positive, we began to improve the design step by step, mak- 
ing all changes in the prototype tooling as far as possible. If 
it was not possible to realize a necessarj' change, new proto- 
type tooling was ordered. Only after tliis iterative process 
was complete did we order the final tooling. 

The idea for the neonatal sensor, Fig. 15, was to place the 
transducer elements facing one another to make it easier to 
apply the sensor on foot or hand, and to have a long strap 
with a special fastener that allows application of the sensor 
on different foot or liand sizes. The transducer is positioned 
on tlie foot or the hand and the strap is threaded through the 
first latch and pulled slightly while holding the top of the 
traiuiducer. The second latch is only used if the strap is too 
long. 
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Fig. 15, Neomtal sensor* 
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Fig, 16» Clip sensor. 

The iciea for the clip spnsor was to integrate the si>iing for the 
necessary clamping force into the molded part (Rg. IGj. The 
transducer is clipped onto the fleshy part of the earlobe. To 
minimize motion artifacts generated by patient movements a 
plastic fixing mechanism that tiooks over tlie eai- is provided. 

Cable and Connector 

Tliree different types of cables are used for the sensor family. 
For the adapter cat>le we use a very robust cable with an 
outer jacket made of polyurethane. The same adapter cable 
is used \^ath all of the sensor types. 

Tvvo differenl sensor cables are used, one for the adult trans- 
ducer aiid anotlter for tiie rest of the family. They differ only 
in the outer jacket. For the adult sensor the outer jacket is 
made of sihcone l>e cause of the nianufactiuing process. The 
sensor housing, wliich is made of silicone, is molded togettier 
with the cable and other elements m a molding machiuc. 
Because silicone can't be combined vei'y well with different 
materials , the outer jacket must also be silicone. 





Fig. 18. LEDtransQiitten 

For the rest of the sensor family we use a split, lightweight 
cable with an outer jacket made of polyur ethane, 

Tlie construction of aO three cables is similai. All are 
t\\isted-pair and have a Kevlar braid anchored m both the 
sensor and the cormector to improve the stiaiii rcUef 

The S-pin connector bctw^een the sensor cable and the 
adapter cable atso has a soft outer jacket made of pol^^ure- 
thane. Tlie Kevlar braid is anchored inside the connector. 
Watertightness is achieved w^hen the two halves of the con- 
nector arc joined (see Fig. 17). 

Optical Components 

The optica element.s are mounted on ceramic substrates 
shaped by cutting with a high-energy laser. The traiismitter 
(Fig, 18) consists of two LED die {y^<i and iiifnired) momited 
on gold metallization. A pliotodiode on the re twelver ceramic 
(Pig. 19) receives the sensor signal. A dome of epoxy material 
protects the elements and bond w^lres from mechanical 
stress. Tlie wires of the transducer and the Kevlai" braid aie 
soldered and anchored on the backside of the ceramic. 

To a firsi approxmiation, LEDs have a Gaussian intensity 
sjiectrum in wliich the peak w^avelength is equal to the cen- 
ti'oid w^avelengtlx. Because the red area ( < 050 nm) of the 



Fig. 17, Cutaway view of two pins of the 8-pirt connector between 
the adapter cable and the sensor cable. Tiie connector is watertight 
when joined. 




Fig. 19. Photodiode receiver. 
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Fig, 20. A typical LED intensity distribution. ForSpOa measure- 
ments the ceiiiroid wavelength gives a better characterixaliofi than 
Uie peak ^"avelength. 

extinction coefficients is verj* sensitive to wavelength varia- 
tion (see Fig- 8) and the intettsity distributjon is not actually 
GauRsian aiKl syninietricalt we use the centroid wavelength, 
whic!i differs slightly from the peak wavelength, as an ade- 
quate characterization paratneter for the LED (Fig. 20)* 
Normally the wavelength \'arialion on a preselected wafer 
for red LEDs is in the rajigc of ±5 nm. For ihe HP M1190A 
sensor in 199(X tiie HPOploclectronics Divisirjti iitstalled a 
selection process for a narrow, ± i-nni ceniroid wavelength 
variation. 

For the new sensor family W' e chose for each sensor an LED 
pair uith centroid wavelengths of 660 nm (red) and 890 nni 
(iti flared). For the red LEID a new^ high-efficiency AlGaAs 
technology w^as chosen. The maxlmimi intensity for these 
LEL>s is about a factor of four higher tiian for the older ones. 
This has the big advantage tliat the transmission values for 
both the red LEDs and the infrared LEDs are about the same- 
The average drive current foi' the LEDs, and therefore tJte 
heat dissipationi can be drainatically lowered* 

The haji.s miss ion Tr is defined as the ratio of photocurrent 
to LED current: 



Tr - 



ph 



LED 



C8) 



where I^^ is in nanoamperes and li^^t) ^ ^^ milliamperes. 
Tr depends strongly on the absorption and extinction coeffi- 
cients of the patient s tissue. Mean values ai'e about 70 iWniA 
over a large patient population. For thin absorbers like tiie 
eariobe, \'alues of Tr as high as 300 tiA/niA are possible. With 
new SpO^;; front-end hardware this would not have been a 
problem, but to be compatible with older pulse oximetry 
instiTiments we tise a smaller active area of the photodiode 
for tlie HP 1 i04A ear sensor to get the same Tr values as the 
other sensors. 

The LED supplier (not IIP for the new sensors) guarantees a 
narrow centroid vvave length variation of less than ± 2 rrtu. 
For LED qttalifi cation mt^asurements. un optical spectnirn 
analyzer with a wavelenglb resolution of 0.2 nm is usee!. Ml 
LED ijarameters are nieiisured with a constant drive current 
of 20 niA. Because there is a wavelength shift over tempera- 
ture of about 0.12 nm/K, ibe mnbient temperature has to be 
held constant* Depending on the LF^D packaging, there is 
also a certain wannuiJ time, which has to be held constant 
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Pig. 21, THTjiral red and infrared LED spectra for SptJ^ sensors- 
The spectral half-bandv^idth for ihe red LED is about 20 tirn and 
for ihe Lnfrared LED aiMUJt 4() iini. A secomlan- emission peak for 

lite red LED is undesired and has to he lower than 4% of tlie 
tnaxiinum intensity*. 

for LED qualification. In clinical practice, there can always 
be a temperature shift dmntig SpO^ measurements, but be- 
cause of the definition of tJ^e ratio j-., with red mtensity in 
the nimierator and infrared intensity in the denominator 
(see equation 6), this effect is compensated within the speci- 
fied operating temperature range of 15^C < T < 45°C, 

Another important factor is that some red LEDs have a iow^ 
secondiuy^ emission ( < 4% of maximum intensit>') at a w ave- 
lengtb of t>'pieally BOO to 850 mn (Fig. 21). For higher second- 
ary' inteasities, interference with the infiTued LED causes a 
ratio error and therefore an SpOa en'or, w^hich must be elimi- 
nated. For the new^ high-efficiency LEDs the secondary 
emissioh is typically less than 0.1%. 

The receiver element is a standard silicon photodio(3e with 
peak sensitivity at 850 nm. The active area is approximalely 
2 mm square for the IIP Mil91/92/93A sensors and i mm 
square for t!ie IIP M1194A ear sensor. The die are mounted 
on a ceramic substrate with metalized layers for shielding. 
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S.5 mm 
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P}i{)todiitile Assemtily 



Ftg* 22* Transn^tter and receiver assemblies for tite new sensor 
family are on ceramic substrates. To avoid asyrnrnetric optical 
shuntinii (penumbra effect) the two LED die are mounted as close 
as p OSS! tile to each other. An epoxy coating is added before final 
packaging to protect the optical parts, 
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Voliuiteer Study for Sensor Calibration 



To cafibrate the new SpQ2 sensor family it was necessafy to adjust ttie 

fefatfonstiip between the ratio nieasurements and the Sp02 values ysing 
data based pn real blood samples from volunteers, 

Rg. 1 shows the measyrement environment for the calibration study. The 

basic instrumGnt is a special HP Component Monitof rng System (CMS) 
with 16 Sp02 channels. Sixteen sensors at different application sites 
could be used simultaneously. To get SpO? values over the entire specifi- 
cation range of 70% < Sp02< 100%, the volunteers got air-nitrogen 
mixtures with lowered oxygen levels — less than 21%. 

Because of his great experience with such studies we used the method 
developed by Dr. J.W, Severinghaus of the University of Calrfomia in San 
Francisco. For each volunteer a maximum of 16 sensors were applied at 
the. fingers, earlobes, and nostrils, A catheter was placed in the left 
radial artery. Arterial O2 saturation was reduced rapidly by a few breaths 
of 100% ^2- Th]S was followed by a mixture of air and N2 with about 4% 
CO2 added while the subject voluntarily liyperventilated to speed the 
attainment of an alveolar gas hypoxic plateau and to provide end tidal 
samples for regression analysis. fi02 was adjusted to obtain plateaus for 
3D to 60 seconds at different Sp02 levels (Fig. 2). At the end of each 
plateau a 2-ml arterial blood sample was obtained and analyzed by a 
Fladiometer 0SM3.multfwaveleng!h oximeter 

The regressfon analysis yielded three Sp02'Vers us- ratio calibration cur\fes: 
one for the HP IVll 190A adult sensor, a second for the HP Ml 191 A adult 
sensor the HP M1192A pediatric sensor, and the HP M1193A neonatal 
sensor, and a third for the HP Ml 194A ear sensor The curves for the 
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Fig. 2. Stepwise desaturation by fowEnng oxygen levels leads to puaslstabfe 
SpOj levels This condiiiGrt gives blood samples wcth correct blocd gas vaiues, 
The delay for ttie SpO? values compared to tha oxyfen values comes from the 
circulation time for the artenai blood from the tungs \o the arm. Calibration 
tables are compiled by comparing the known Sp02 values with the ratio data 
measured hy the CMS. 

HP M 1 1 BOA and M n 91 A are different because of their different LED 
wavelengths, u^'hile for the ear sensor the application site is different — 
the tissue constitution of the earlobe and nostril seems to be optically 
very different from ihe other application sites. Each calibration curve is 
the best least squares fit to the data points of a second-order polyno- 
mial. 




HP CDrnponent 
MonitorJng Sv^tem 
IB SpDz Channels 



Arterial Blood 
Sample 



OS Ml 
Oxintetcr 



Ijtplop 
Cmfiputer 








R9, 1. Sensor calibration using volon- 
teers and SpOz data acquisition by a 
special HP Component MonitDring Sys- 
tem (CMS) with a maximum of 16 
channels. Different Sp02 values are 
achieved by supplying different mix- 
tures of oxygen and nitrogen. Artenal 
blood samples are analyieJ by a Radi- 
ometer 0SM3 oximeter For each sen- 
sor arid application site, regression 
analysis is done, anij calibrating tabl&s 
are derived from the results. 



The package for the LEDs hi the HP MllfJOA sensor v^'as a 
standaid siibniiiuatiuT package. The emitter consist efi of a 
red -infrared-red triplet in a longitudinal aiTangeiiient 10 
make the apparent emission points for the red and infraiefl 
sources \irtiiaily identic^il. This is impoitant for the ratio 
calculation, because both hght paths have to be about tlie 
same length. One disadvantage is a possible malfimction 
wjien the patient s fmgcr does not cover the enriie hght 
source. Tlien a pa 11 of the red Hght can cause ai^ optical 
shunt that yields dc red levels that are too higli (penumbra 



effect), causing false liigh readings. In the new sensor dch 
sign, the two LEDs aie veiy close together (< 0,5 mm) on a 
common leadframe (see Fig. 22). This should eliminate the 
penimibra effect. 

The die are momited on a ceramic substrate and covered 
v'^'ith a transparent epoxj' material. A design goal was to gel 
a water and ciisiiifectanl resistaiit seal between the cable 
aaid die package, lintnersion ai\d disinfection tests show that 
rjiis goal was achieved. 
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Fig. 3. Regression anaiysfs for HP Ml 191 A aduU sensor SpOj nneasurements 
after calibraiian The meastjrefnenis are plotted against artefial blood SaO^ 
measurements from the 0SM3 oximeter. Tiie data [206 points) is from 12 
volunteem with differem oxygen saturatfon levels. 

Fig. 3 shows XhB good cornelation witti the reference (R^ = 0,95) in the 

case of the HP Ml 191 A adult sen sot Fig, 4 shows that the specified 

SpO^ accuracy is reached within the range of 70% < Sp02 < 1 00%, 
Fig. 5 shows that the correlation for the HP Ml 194A ear sensor is not as 
good as for the HP M1 131 A. The data pomt distnbution is also wider 
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Fig. 4 Bias and standard deviaiion for the HP Ml 191 A over the specified 
rangeof7Q%<Sp02<:100%. 
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Fig. 5. Hegression analysis for HP Ml 194A ear sensor SpO^ measurements 

after calibration. The measurements are plotted against arterial blood SaOj 
measufements from the 0SM3 oximeter for 12 volunteers. 



(Fig. 61 This is caused by a much poorer signal quatitv at the earlobe 
than at the finger In general the perfusion index for the ear is only 
about a tenth of that for ^e finger. Therefore, in normal circumstances 
the preferred application site is the finger In same cases, such as cen- 
traljzation [i.e,. shock patients), the eariobe sometimes gives better 
results. 
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Fig. 6. Bias and standand deviation for the HP Ml 194A The standard 
deviation is larger than for the HP Ml 191 A because of the smstler perfu- 
sion values m the ear 



Materials 

For the pediatric and neonatal sensors we chose silicone 
with a hardness of 35 ± 5 Shore A. The material is very 
robust and has good tensile strength compared to other 
silicones. Silicone is very often used in clinical m'e^s and is 
veiy well-accepted. It is very' resistant to chemicals and 
causes no skm irritations when iised correctly. 



For the clip sensor we chose a polyurethane with a hardness 
of 75 ± 5 Shore A, which gives the required clamping force 
(Fig. 23). 

Manufacturing Process 

The lUiiimfatlnjring process for the new HP Ml 191 A sensor 
is iiyection molding, the same as for the older HP Ml 190A. 
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Fig. 23. SjniiiM tVirc-t^H let Uii.-^ vXiy sifjjsuj'. 

These seasons use only silicone nibbcr. For the HP Ml 192/ 
9t3i/94A sensors a different manufacturing process was nec- 
essary becau.se these sensors use two different materials — 
silicon iiibher and polyuretliane^ which do not combine weO 
in the ii\jection molding process. We also wanted to lefluce 
the manufacturing costs and to gain more flexibility in 
choosing suppliers. 

We decided to cast, the prenwunted optical elettients together 
with the cable in a special epoxy that combines very well 
^A\h the cable including tJie Kevlar braid. We thus ensured 
waterlightness, which means the sensors can be disutfected 
by inuttersion in solutions. 

Reliability 

To reach the rehabihty goals a few iterative changes were 
necessary and different tests uistalled. Matiy tests and cus- 
tomer visits were c<jnducted to ensLu-e that the sensors will 
not break. We tested seventl housing materials mitil we foimd 
tlie right one for tlie rough clinic aJ environment. The tensile 
strength and robustness have been improved dramatically 
compared to the first samples. The method of arichoring the 
Kevlar braid in the ceramic substrate and connector was 
also improved several times. Eveiy prototype was tested hi 
the same way, by a combination of mechanical stress and 
cleaning by inmiersion in different solutions. 

Technical Quallfieatloii 

The most inipoilani factor for qualifying the new Sp02 sen- 
sors has beet^ how to detennuie test methods that aic able 
to expose any weak points oftlve design. The qualification 
stress should be higher tlian the nonnal clhiical application 
stress to provoke failures. The fulfiltment of cnstotner exi^ec- 
tations concermng reliability was the overall guidelme for 
prioritizing the test emijiiasis. Because of its customer 
orientation, the QFD methodology w^as an excellent tool for 
determining the main focus for testing. To make QF'D more 
practical, w^e divided the sensor into tliree subelenienis, 
w^hich made tlie specifics of the subassembly more \isible. 
The ttiree subeiements were the inter connection^ tlie sensor 
housings, and the optical assembhes. 



The correlation matiix between the customer requirements 
and the teclmical specitications generated a relative impor- 
tance ranking within the broad Ust of requested teclmjcal 
details. We could now deteniiine which were the most 
important teclinical parameters. Their perfonnance would 
have the greatest impact on the acceptance of the sensors in 
the market. 

It was very important to assess the technical comijlexities 
and difficulties in the reaJization of technical specifications. 
This was the task of the engineers of a crossfunctional team 
chosen for their exjierience and ability to foresee potential 
problems. The correlation betw^een expected technical diffi- 
cutties and tlie importance of the parameters to Oie customer 
w^as an essential input for further activities. We could now 
focus our efforts to reduce the risk potentials, wliich w^ere 
clearly defmed. liigh risk means higli importance correlated 
with high technical difficult^' ratmgs. These high-priority 
items w^ere communicated to the project managers to give 
them an impression of the degree of technical maturity in 
this early project phase. 

A critical assessment of design risk potential could now be 
made. Tliis tiiggered a review^ of the importance of each 
customer requirement and gave the designers valuable m- 
puts for design concepts. The results were also useful w^hcn 
considering strategies for accelerated stress testing. 

The next step in the QFD process w^as to transfer the infor- 
mation on higli-priority technical requirements into another 
matrix showing tlie relationship between paits characteristics 
and technical requirements. The key dehverables of this 
exercise were: 

• Identification of key parts and their characteristics 

• Preseleclion of parts characteristics to find critical parts 
for performing a design failure mode and effect analysis 
(FMEA) 

• Information to aid in selectuig betw^een design alternatives 
to tind the most competitive design concepts 

• Inputs for stress testing using parts characteristic impor- 
tance inlbrmation. 

The FMEA generates risk prioritj^ numbers (RPN). Tliese 
numl>ers describe how often a failure will be occur, how 
easily it will he detected, ai^l how severe the faihire will be* 
Taking the uiterconnection as an example* the risk assess- 
ment W'OS divided mto tliree categories: 

• High Risk: RPN > 200 and high parts impoitaiice 

• Medium Risk: RPN > 100 and high parts importance 

• Low Risk: RPN > 100 and low parts importance. 

hi this way, key customer needs w'ere identified and test 
parameters selected. We also took into accomit the feed- 
back from clinical trials. 

Fig. 24 gives an overview of the quahfication tests that w^ere 
performed to get release approval for the seasors^ A special 
mactune was designed to simulate the cable stress that 
occurs iti hospitals. We call this test the bending/torsion test. 
Witli a calculated number of cycles, equivideni to om- reli- 
abiht>^ goals, we stressed the critical cable sections to en- 
sme that the lifetime requirements were met. 
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Fig. 24- Qualiflcatiori tmts for the new semor family. 



Supplier Selection 

Tlic supplier c-hosen to nianufactiire the new SpOa sensor 
family Iiarl lo meet a number oF specific requirements. The 
supplier is responsible for Uie lu^jfjrity of the manufacturmg 
process steps. This has a positive iuflueuce on pHxluction 
lead time, logistics, communication, and cost-s. To reach our 
quality goals with one supplier who is respotLsible for nearly 
till process steps is much easier thati with a long chain of 
suppliers. The requirements covered technology, vertical 
ijviegration, and costs. 

Fourteen inteniational suppliers were evaluated. Nme were 
not able to nianufarhite the sensors becatJ.se they did not 
liave Ute rcquirini UH'hru>logy. Mer considering cost ^tspects, 
only two supi>liers fulfilled the selection criteria. For these 



two suppUers, w'e constnicted supplier iimfiles derived from 
the QFD method. 

To constmct a profile, each customer need is listed along 
with an evaluation of how^ w^ell the supplier fulfills that need 
In terms of te<'luiol(jgy and processes. Tlu* level of rulfilhtient 
is evaluated by an HP specialist tcimi, which als«> evaluates 
the impoilance of each customer need. The profile sliow^s 
the supplier*s strengths tmd w eaknesses and gives a point 
score. The supplier with the higher iuiinl>er of points is con- 
sidered better qualiJleti to mtuiufactiit'e ihese products. 

To evaluate critical technology and processes, design and 
procress failure mode iind effect analyses (FMEAs) %%^ere 
conducted tor both suppliers' [iroducts. To evaluate each 
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Neonatal Sensor Cliiiical VaLidatioii 



In contrast to the voiunteer study with adult subjects (page 481, a vaiida- 
tlon for the HP M1193A neonatal sensor had to be done with neonates in 
a clinicef environment Because blood sampling is very critical for sick 
neonates, only wiien an artefsal iine was aEready m place for therapy 
could we get bJood sample values. F»g. 1 shows the regression line for 




QSMBSaOj Reading [^d| 

Fig, 1, Regression analvsss with dats from clm?cai trials with ttie HP M1193A 
neonatal sensor. T)ie 290 data paints are derived from 20 subjects who aEready 
had an arterial line for blood sampling. The arteriaJ Sa02 values were measured 
by an 0SM3 o.xuneter. 



290 data points from 20 subjects, The correlation |R^ = 0.911 is good 
considering that neonates often have oxygen saturation states thai are 

ur\stable and changing rapidly. To eliminate these uncertainties, Sp02 
values with big differences before and after blood sampling (ASpOg 
>5%) and with poor signal quality (perfuston index < 0.2) were not 
included. Fig, 2 shows that the specified accuracy of 3% Sp02 standard 
devration for the range 70% < Sp02 < 1 00% has been reached for the 
HP Ml 193A sensor based on the chrtical data from neonates. 




70 BQ 

QSM3 SaQi RQadinff {%\ 



too 



Fig. 2. Bias and standard deviation for the HP Ml I93A neonatal sensor within 
the specification range of 70% < SpO? < 100%, based on data from 20 neo- 
nates. 



manufacturer's capabilities, a quality aiid process autiit was 
perfoniied at tlie maimfactiiriiig sit*^. Tlie auditors reviewed 
the site and manufacturing processes for comparable prod- 
ucts diat were identified as critical for oui' sensor products. 

Production Wavelength Measurements 

The measurement of LEDs for the SpOa sensors at die man- 
ufacturiug site is a critical atui sensitive manunicturing pro- 
cess step. To guai'antee the accuracy of HP SpO^ measure- 
ments the wavelength of the red LED has to he within a very 
sn\ali range: beti^'een 657 and 661 nm. To measuie the LED 
wavelength a very accurate optical specti'ometer is used. 
To obtain repeatable measurement results, an integrating 
spliere is used to couple the hght of the red LED into the 
spectrometer (see Fig. 25). 



RflflHciar — , 
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Fig. 25, Setup for LED spectral meajsurements. 



An integrating sphere is a ball with a highly reflective sur- 
face. The light is reflected many times on the surface and 
becomes diffuse. As a result, the spectnnn and the uitensity 
of an LED aix* the same at each point of tlie siuf ace of the 
ball and can be coupled easily into the spectrometer The 
main advantage of this method is dial tolerances in the place- 
ment of tlie LED are not critical and the repeatability is very 
good compared to other methods. Fig. 26 shows a typical 
spectium of a red LED measured wirJi an integrating sphere. 
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Fig. 26. Spectrum of a red LED measured s\1rh an integrating sphere. 



52 Febmajy 1997 Hewjett-Patrkard Joumal 



)Copr. 1949-1998 Hewlett-Packard Co. 




Pig. 27, BP UnmA dip senson 

There are tliffereiU ways to measure ihe wavelength of m\ 
LED. One is the peak w^ave length, which is the highest point 
Qf the spectrum. The centroid waveleiigrh, which is used in 
our measurements, calculate*^ the renter uf Uie area under 
the spectrum. A secondary peak in the spertnmi of the LED 
can have a large influence on the measurement results and 
has to be very small ( < 1%). 





Pig. 29. HP M1193A neonatal sensor. 

Tlie temperature of the LED die has a large influence on the 
emitted wavelength — the higher the temperature the higher 
the wavelength (0A2 mn/K). Therefore, the LED must be in 
rhennal equiUbrium. In practice, the LED takes only a few 
seconds to reach thennal equilibrium. The ambient tempera- 
Ture must be monitored and if the temperature changes the 
spectrometer must be recalibrated. 

Summary 

A new family of reusable pulse oximetr>' sensors has been 
developed. Based on the HP Ml 190 A. HP's first reusaljle 
SpO^ sen.son these sensors can nuninvasKely monitor the 
blood oxygen levels of patients, a key \ital sign. They are 
used primarily in operating rooms, recovery rooms, intensive- 
care tmits. and some general wards. Ttie new sensor family 
covers ail application areas and coasists of tlie M1194A clip 
sensor (Fig. 27), the HP Mil 91 A adult sensor vnth new^ wave- 
length (Fig. 28), the HP M1192A pediatric sensor (Fig. 12), 
and the HP MH93A neonatal sensor (Fig. 29). 

Ac kno wledgments 

Many people were involved In this project. Tlie authors 
would especially like to thank Diet rich Rogler for the indus- 
trial design of the sensors. Willi Kemi and Peter Jansen of 
materials engineering for their excellent supjioit, Martin 
Guenther for performing all the optical characteristic's mea- 
surements, Gerhjird Klaniser for verU^ing the algorithm, 
Gerhard l^nike f<jr tjrganizing all the regulation tiisks, atid 
Otto Getitner for n^anaging the clinical trials. Spot ial thanks 
to Professor Dr. J. W. Severingliaus of the llttivej'sity of Cali- 
fornia Hospital in San Francisco for performing volunteer 
studies. 

References 

1. T„I Hayes ajid E.B. Merrick, "Continuous, Non-Invasive Measure- 
ments of Blood Ox>'gen Levels, "" Hewielt-Fackatrl Journal, VoL 28, 
m. 2, October 1976, pp. 2-10. 

2, HeivtefJ-Parkiifd Joamal Vol 42, no. 4, October 1991, pp. 6-54. 

3. D. Clausing, "The House of Qufihty/' Bumness R^rif^tt\ May-.lune 
1988, 

4, LP. SullivaiL "Quality FuncUon Deployment" Quality i^v^ress, 
June 1986, pp. 39 50. 
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Design of a 600-Pixel-per-Inch, 30-Bit 
Color Scanner 



Simply sampling an image at higher resolution will not give the results a 
customer expects. Other optical parameters such as image sharpness, 
signal-to-noise ratio, and dark voltage correction must improve to see the 
benefits of 600 pixels per inch. 

by Steven L. Webb, Kevin J. Yonngers, Michael J. Steinle, and Joe A, Eccher 



The objective of a scanner is to digitize exactly what is on 
Uie tloc anient Uial is being scanned. To tlo this perfectly 
would rtxiiiire a CC'D (cliarge conpled device) delectfjr mth 
an innnile niunljer of pixels and a lens with a modulation 
(nmsfer fimction of 1.0, which does not exist, Modtilation 
trarusfer fiinction, or MTK is a measure of tlie resolving power 
or image sharpness of the optical s-ystem. It is analogous to 
a visual test that an optometrisl woiild use lo measure a 
huiiuni eye's resolving power 

In the real worlds the scanner user does not require a perfect 
reproduction of ihe original because the human eye does 
not have infinite resolving powen However, as originals are 
enlarged and as printers are able to print fmer detail, the 
imagmg requirements of the scanner are increased. 

The HP ScanJet 3c/4c scanner, Fig. h is designed to obtain 
very fiiudy detailed images for a variety of color and black 
ai^d while chjcumeutsiind three-dimensional objects tl\at me 
typically scanned. Its optical resolution is 600 pixels per 
inch, compared to 400 pixels per Inch for the earlier HP 
Scautlet lie. It produces 30-bit color scajis compared to the 
ScanJet He's 24-bit scans, and its scaiming speed is faster. 
The ScanJet -Jc and 4c differ only in the software supplied 
with them. 

Optical Design 

The HP Scarirlel 3c/4c optical system is similar to that of the 
HP ScanJet Oc scaimer,^ with improvements to increase die 
optical resoluMon to 600 pixels per inch* Just sampUng an 



image at higl^er resolution will not give the results a customer 
expects. Otlier optical param eld's , such as MTF (le., image 
sliartjuess), signiil-to-noise ratio, mtd diu"k \ oltage correction 
nuisi unprove lo see the Ivenetlts of 600 i)ixei.s t^er incli. 

The mtyor optical components are: 

• Two laminated dichroic composite assembhes used for 
color separation 

• A fluorescenl lamp with a custom mixture of phosphors 

• A six-elenienl double Gauss lens 

• A tln'ee-row CCL) sensor thai lias 5400 pixels iwr row 

• Four front-surface mirrors. 

Tlie color separa! or composites, double Gauss lens, and 
CCD are shown in Fig. 2. 

The color separation system (Fig. 3) consists of the two 
diciiroic asseml>lies and the three-sensor-row CCD. With this 
method, red, green, and blue are st aimed simultaneously, 
so only one pass is needed to scan all thiee colors. Each 
dicliroic assembly is constructed of three glass plates that 
inQ bonded to each other with a thin layer of optical adhe- 
sive. Red, green, and blue reflective dichroic coatings are 
deposiied onto the glass before lamination. The order of the 
coatings is reversefJ for the second dicliroic assembly. The 
Thickness of the glass plates between the color coati^igs and 
the llatiiess, tilt, and aligmnent are precisely controlled to 
ensure accurate color separation and image sharpness. 



CCD DeteclDT 




Fig, 1. HP ScanJet 4c 660-dpi, ao-bii color scanner. 



Fig, 2. Lens, CCD (cliai^e-caupled device) detector, and color 
separator composites. 
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Color Separstqr 




Analog ¥\bx Circuri 



Fig. 3, The cokir st^paratioii 
inetlitHJ uses two ciJctiroir 
assemblies (composites) and 
a three-row CCD. 



Each color component is focused onto a CCD sensor row 
consisting of 5100 imaging pixels. Additional pixels are used 
for closed-loop dynaxiric light control, dark voltage correc- 
tion, aitd reference mark location. By having all tltree rows 
mtegrated onto a single silicon clii|). precise distatices be- 
tween the tliree rows are ohtained. Prodnction consistency 
is guaratiteed by the integrated circtiit process. Each CCD 
pixel generates a voltage signal that is proportional to the 
amount of light focused onto each pixel. Hie signal for each 
pixel is then processed and digitized. Tliis data is sent to a 
computer or a printer 



Foe lis Optimization for Each Color 

Two dichroic assemblies are used to equalize the path 
lengths of the three colors. A six-element dotible Gauss lens 
is used to focus the tight onto the CCD sensors. However, 
the variation of the index of refraction of glass as a function 
of wavelength causes two of the three coloi^ to obtain opti- 
mum focits at different locations. This phenotiietTon of dif- 
ferential refraction caused by wavelength dei>endence is 
best detnonslraied Viy holding a pnsni up lo a white light 
source and observ-ing the colors. The light spectrum is sepa- 
rated because the shorter wavelengths (blue) are refracted 




Red, Qreen and BJua tt^cus 
in DiWefeni Image Platies- 




Red, Green end Blue Focits 
on Same Image Plane. 



Fig* 4, (a) Chroniaiir almrratlna of an tiuctxrreeUHl sy.stejtL Xi = Xm = X:i = X^. lb; To pusure that sinitiltaneous focus for red, greeu, 
and blue is achieved in tl:ie HP ScanJet; Bd4c scanner^ unequal path lengtlmare imnl to {^ompens^ite fur the ebrtJiuatic atx*rration of the 
lens. XI = X:l mid X2 = X4, Ijui X2 ^ XL 
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Fig. 5. CCD row lengths are actjiisted to compensate for color 

separator plate thicknesses. 

or bent more than the longer wavelengths (red). Since 
lenses are made of glass that refract Ught of vaiying wave- 
lengths at different angles, it is difficult to have all three 
colors focus at the same location. 

To acliieve simultaneous focus for ail iliree colors there are 
several possible solutions. One is to design the focusing 
optics with cun'ed fi'ont-surface mirroi-s only. However, 
these systems can be expensive, and it can be hai^d to cor- 
rect otlier optical aberrations and difficult to image enough 
light onto the CCD. Another possible solution is to use an 
achromatic doublet. However, this type of lens can mininiize 
chromatic aberration for only t^^o of the three colors. 

The ScanJet 3c/4c scanner optical design minimizes the 
chromatic abenation caused by the lens. An uncorrected 
optical system is shown in Fig, 4a, and a correct ed optical 
system is shown in Fig. 4b. Lens chromatic aberration is 
corrected by adjusting the thickness of the dichroic coated 
plates. The path length of each color is adjusted to obtain 
optimum focus. 

Unequal path lengths for red, green ^ and blue would cause 
color registration error across the scan region. To prevent 
this, the CCD sensor row lengths are adjusted as showTi in 
Fig. 5. Eaclt row has the same nimtber of pixels. However, 
the center4o-c enter spacing (i:)ixel pitch) is slightly larger 
for a small number of pixels in rows 1 and 3. The pixels with 
slightly larger pitch are strategically placed to connect for 
the lateral chromatic aberration of the lens. This eliminates 
any color registration error that would have been caused by 
the lens. 

Optical System Layout 

The lamp, lens, mirroi's, color separators, and CCD are 
mounted into an aluminum carriage that is translated or 
scanned along the length of the doctunent. The carriage is 
pulled midemeath the glass platen by a belt comiected to a 
stepper motoi'. Tlie optical layout is shown in Figs. 6 and 7. 



Fig. 6 shows the meciianical design model of the carriage 
and light path. Fig. 7 shows pan of the light path In more 
detail. 

The optical system was designed and evaluated using a com- 
mercially a\'aiiable optical design program. Tlie sensiti\1ty of 
optical tolerances such as lens centeringj radii, tliicknesSt and 
index of refraction were evaluated to determine the effects 
on image quality. The manufacruring assembly aiul mounting 
tolerances of key optica] coniponents in the caniage assem- 
bly were also evaluated. Image qiiality parameters such as 
MTF, color registration error, illumination uniformity, and 
distoiHon were emphasized. 

To achieve precise optical alignment, custom assembly tool- 
ing was designed and implemented to meet production goals. 

Fluorescent Lamp Driver 

The fluorescent lamp is driven by a circuit that allows the 
lamp current to be varied over a range of 90 to 425 milh- 
amperes. Since the lamp output is proportional to current, 
the lamp m tensity is also varied. 

A block diagram of the Lamp driver circuit is shown in Fig. S. 

The control inputs to the circuit provide the following 

ftmctions: 
' PHEHEAT_L allows the filaments to be heated before the lamp 

is ignited, 
' LAMP_PWM provides a pulse width n\odulated signal to set 

the desired current level. 
1 LAM PGM_L turns the lamp on. 

The filaments of the lamp ai'e preheated for one second be- 
fore lamp turn-on to reduce the amount of Hiament material 
that gets deposited on t he insides of the glass. The deposits 
reduce light output, causing the light level to diop off near 
the ends of the lamp. This could create a lamp profile prob- 
lem if preheating were not implemented. 

Tlie LAMP_PWM signal provides the desired current level plus 
a sync signal to the oscillator. The switching of tlie lamp 
driver power transistors occius while the CCD (charged 
coupled de\ice) is being reset. This helps keep switcliing 
noise from contaniinatung the CCD measurements. The lamp 
cuuent command is derived from LAMP^PWM \1a the low- 
pass filter. The output of the low-pass filter is a voltage pro- 
poriiional to the amoimt of current desired. 




Fig. 6, Mec;hai"Lical desjgn laycjin. of tlik- HI'' ScanJet Ckv^c optica] paih. The liglii patl"t is frum the scaii LLiie to mirror #1 to niirror #2 to 
mirror ^3 to mirror #4 to tlie lens to the color separa.tor to the CCD detector. 



56 FcbrLtary 1 997 Hewlett-Packard Joum aJ 



)Copr. 1949-1998 Hewlett-Packard Co. 



Color Separstof Assembly 




v!^: 



Mirror 94 



'— S(i^£^eEn«iii ism 



Fig, 7, Ray trace of the optieal 
liSLth from mirror #4 to the color 
separator assemblv fone color 
only). 



The LAMPON_L signal holds the flip-flop in the set mode until 
it is time to rtim the lamp on. When the Olp-Oop is set, power 
FET 1 is held off \ia the buffer. 

Operation of the lamp dm^er begins by taking Pf^EHEAT^L to a 
logic zero. This allows the di^ide-^by'2 circuit to begin rog- 
gHng. When PFIEHEAT_L is high, bolh Q and Q are high, which 
turns off power FETs 4 and 5 via the inverting buffers. The 
toggling of the divide-by-2 circuiT drives power FETs 4 and 5 
out of phase. Tliis provides a 24'Vok square wave on tlie 
primary of Tl which is stepped down to 3.6V to drive the 
filaments, VVlxen LAMPON_L is activated, the Oiivflop is reset 
on the next LAMP_PWM pulse, turning on power FET 1. The 
lamp appears as a high impedance in the off state, which 
results in power FETs 2 and 3 avalanching as a result of col- 
lapsing magnetic fields. The avalanche voltage of the powder 
FETs is approximately 120 volts, half of which, or GOV, 
appears at the center tap of Tl. This voltage is multiplied by 
the 1:6 turns ratio of Tl to produce 360V across the lamp. 
This voltage starts the lamp and the voltage drops to the tow 



forty volt range. Current now no\¥ing in the lamp is reflected 

hack to the primarj; where It is sensed. Amplifier -3 amplifies 
the \ oltage across the sense resistor and ainphfier 2 sub- 
tracts it from the ciurent command (output of amplifier L). 

The output of amphfier 2 is passed through the loop com- 
petvsator (proportional plus integi^) and applied to the 
comparator. The oscillator output is applied to the other 
input to the comparator, in the steady state, the loop com- 
pensator will stabilize at a voltage that produces the proper 
duty cycle on power FET 1 to maintain the conmianded cur- 
rent. At this time the voltage across the 50-pH inductor ulil 
be in volt-second balance."^ 

All of the low-power analog and digital circuits are contained 
in an analog ASIC. 

• The voltage acro&s ih€ if^diJcTor switches fram pQShtEve to negative as The FET turns un and off. 
When ihe praduct of the positive voJiags and its duraticn equals ttm product al ihe r>egaDve 
voltage and it$ duration, the mduotor voitige is In vDit-second balance 



+ 24 Volts 



FluorNcent 



LAMP_PWM 



PftEHEAT.L 




Fig. 8. Block diagram of the fluorescent lamp driver. 
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Kote: Adjacem lines are on 
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Scantier Haad Positiait 
Fig, 9, StarE-3lop profile. 

Firmware Design 

Tlip finiiwaje insicie Ihe ScanJet 3c/4c has many tasks. Two 
of the most ciitical (anci most interesting lo work on) were 
tlie stait-stop algoritlim and the light control algorithms. 

Start- Stop. Ditriiig some scans the host computer's I/O rate 
may not be able to keep up v^ith the scamier's data genera- 
tion rate. This will cause the internal buffer in the scanner to 
fill Wlien this occurs the scanner may need to stop iind wait 
for the host to catch up (empty the internal buffer) before 
restarting the scan. Tins is called a start -stop. The scanner 
must restart the scan in the same place that it stopped or the 
user will see art.ifacts in the final unage. If tlie scanner's drive 
system cai\ start and stop within a fraction of the y-direction 
sampling size then no repositioning is needed. U die scar\ner's 
drive system caiinot stop or start fast enough then it must 
back up and reposition the scan bar to be able to restart at 
the correct location (see Fig. 9). 

The ScanJet 3c/4c uses variable-speed scanning in the y- 
direction (along the length of the scan bed). VaJ'iable-speed 
scanning has tvs^o main advantages: better y-direction scaling 
and fast scan speeds at low resolution. The ScartJet3c/4c has 
a wide range of scan speeds (20 to 1), so the drive system 
needs some acceleration steps (of tfte stepper motor) to 
reach most of the final scaiming speeds. This also means 
that tlie drive system cmmot start or stop in one step. This 
dictated the need for a reposition movement for each start- 
stop. 

There are three parts to a start-stop. First, when the internal 
buffer becomes fiillj the fiimwai'e marks the position and 
time of the last scan line and stops the drive system. Second, 



the firmware caicuiates how far to back up ^md then backs 
up and stops. Third, when there is enough space in the inter- 
nal buffer the fimiware accelerates the drive system up to 
tlie correct scanmitg speed and then restarts the scan line a! 
the correct scan position. 

The scanner firmware conU'ols the step rate of the drive 
system. It uses its internal timer with a hardware interrupt 
to control the time between steps precisely. Dming accelera- 
tion, the tirmw'are gets the next time inter\^al from the ace eh 
erat ion table. Once at the proper scimning speed, the time 
inteival is constant and die tiiTiiware just reloads the timer 
with the same hiterval. Deceleration uses the same table as 
acceleration 'u\ the reverse order, 'fhe finnware also keeps 
track of how many motor steps have occurred. Each motor 
step represents 1/1200 inch of travel for the scan liead. This 
allows the firmware to keep track of the location of the scan 
head. 

The scanner firmware also keeps track of when each scan 
Ime occuis (relative to a motor step). The scan lines are 
spaced 4.4h ms apart (for nomial speed), A scan line may 
coincide with a motor steji or may be between two motor 
steps, depending on the y-direction scan resolulion). For 
exmnple, for a GOO-dpi scan there are exactly two motor 
steps for each scan line (2 x 1/1200 = 1/600, so the scan 
head moves 1/600 inch in 4.45 ms). For a 500^dpi scan there 
would be 2.4 motor steps for each scan Une. 

\Vhen restarting tlie scmi, Ihe firmware must restait the 
CCD at least seven scan lines before putting scan data into 
the buffer This is to allow the CCD to flush any extra charge 
in the system caused by restarting the CCD. Tlie niunber of 
motor steps for seven scan hues depends on the y-direction 
scamiing resolution. The number of steps to accelerate also 
depends on die y-dircction scannmg resolution. There is 
also a minimum nimiber of steps that the drive system must 
be backed up lo remove tuiy mechanical backlash. These 
requirements determine the number of steps the scan head 
must be backed up (see Fig. 10). Once tliis is determined the 
finnw^are backs up the scan head and w^aits for the host to 
remove enough data from tiie internal buffer 

The internal btiEfer capacitj-^ hiside the 3c/4c scanner is 256K 
b^tes. Under the DOS operating system a typical receive 
block is 32K bytes (it can be laigcr). The ScanJet 3c/4c wiQ 
restart a scan w^hen tiie buffer is half full or holds less than 
twice the current receive block sisse, whichever is less. 

Once there is enongJi space in the buffer the fimiw^are re- 
starts the scan. First, the scan head is accelerated up to the 
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Sing to Me 



The HP ScanJet 3c/4c scac^net uses variable y^dffection scanriing. Tliis 
means that the scm head travels at differed speeds dependertt on the 
V resofjUon This also means that the stepper motor runs at ^'ariabie 
frequencies. 

Musical notes are m vro rat ions at gwen fre - lay Tune 

\ Esc*iiOM} IS an SCL (Scanner Contml LangL :: ^ ^nd that can be 

used 10 make the scanner piay any song downloaded mto its fruffer. The 
song can be loaded into the scanner's internal buffer using the SCSf 
write buffer command The fonnat for the song rs number of notes 
(2 bytes), note one, note two, eic. Each note is three bytes. All numbers 
are in hexadecimal format. 

The first two bytes of each note specify the number of 3-MHz clock 
cycles between full motor steps for the desired speed. The third byte is 
the note duration in multiples of approximately t/8 second- For example. 
middle C is 256 Hz. The clock frequency ^s 3 MHz, and the motor half- 
steps. For middle C, therefore. 3.000,000 clocks per second x 1/256 
second per full step x 1/2 full step per half step = 5853 clocks per full 
step, which in hexsdecJmgl is 16E3. For the third byte, a 4 would move 
the motor for 1/2 second (4/8 = 1/21 Thus, to get the scanner to play a 
1/2-second middle C, the number to download is 16E3. 4, 



For a rest betw^n notes, set the frequency to zero ami the duration to 
tt^ desired fength of the rest Whei^ playing notes, the scan \^^ al- 
ways moves towards the center of the scannef and any frequency 
above the maximum scan rate of the scanner is truncated to the maxi- 
mum scanning speed. This gives the ScanJet 3c/4c a three^tave 
range with the lowest note at atxjut D bekiw middle C 

Here is a well-known tune by Mozart I don't download the spaces or 
commas J 

02£ 

ICES, 6 16E3,6 Of 47, 6 Of 47, 6 Od5c,€ OaSc,6 

Of 47, 9 00.2 

1125,6 1125,6 122a, 6 122a, 6 1464,6 1464,6 

16H3,9 00,2 

Of47,6 0f47,6 112S,6 1125,6 122a, 6 123a, 6 

1464,9 00,2 

Of 47, 6 Of 47, 6 1125,6 1125,6 122a, 6 122a, 6 

1464,9 00,2 

lgB3,6 ieE3,6 0f47,& 0f47,6 Od9c,6 0d9c,6 

Of47,9 00,2 

112S,6 1125,6 122a, 6 122a, 6 1464,6 1464,6 

16E3,9 



final scanning speed. A hardware interrupt is programmed 
10 restart the COD exactly seven scaji lines beff:*re the posi- 
tion at whifh tt^e last scan line was put into tlie buffer. Then, 
half a scan line away front Uie restart position, the buffer is 
reenabletl such that the next line is put into the buffer At 
this p^iint the scaJi has been restarted and the stait-stop is 
completed. 

Tlu^ .si an s\ op accuracy of the ScanJet 3c/4c scanner is spe- 
t ified at half the y-directlon scanning resolution* The typical 
rest >lu( ton is between one-eighth and one-quarter pixel at 
the nonual speed. 

Light Control The lajnp in the Scan^Jet 3c/4c scanner is a spe- 
cial triphosphor fluorcscenl bulb- Using a fluorescent bulb 
has a numt>er of trade-offs, Tlie good news is llial fluores- 
cent bulbs have a range of phosphors to choose from. Tliis 
allows the designer to balance the light spectrum with filters 
to give good colorimetric performance. The three phosphors 
in the ScanJet 3c/4c scanner give off red, green, and blue 
lig]it, Florcsceni bulbs are also efficient, and give a reason- 
able amount of li^hi for the energ>^ used. 

The bad news is that tlie intensity of the hght is dependent 
on the bulb temperature. This means that as the bulb heats 
up the light gets brighter If the bulb gets too hot, then the 
light gets tUinmer again. Uliat is worse, the bulb does not 
heat evenly across its length. Tlie ends heat tlrsl ainl fastest 
aiul then the center c}f the bulb slowly heats up. Tlie phos^ 
phors also have different efficiency-vers us- tempera tore 
charaeterislics. This mejuis that as the bulb heats up, it 
shifts color. At some nominal temperature, anrl cndy at that 
teni])eratnre. the phosphors are at their design c^fllciency. 
and tht» light is balanced with the filters, UTtat niakes this 
really bad is that the liinc it lakes to romplete a scmi viu\ 
vary between ir> seffinds and 'j minutes. Fluorescent bulbs 
also have a long-ienn aging eflV»ct — a decrease in efficiency 



that affects performance^ — and the phosphors we have cho- 
sen age at different rates. 

One solution to some of these problems is to leave the light 
on aJl the time. Then tiie bulb is at one stable tempemtiu'e 
for the full scaii. This solution has its own set of problems. 
For example, die bulb needs to be customer replaceable and 
the power consumption of the miit is high during idle time. 

The ScanJet 3cy4c solves some of these problems with a 
real-time control system that ctnitrols the output of the light 
by modifting the power into the l>ull> during a scan, ll also 
has separate red, green and hi up system gkuns that tu-e ad- 
justed each titne the light is timaed on to help balajice the 
overall color of the system. The light control system in the 
Srat\-Jet 'k'/4c uses the same VCD that is used for scanning, 
TIk^ CCD Is wide enough so that it can look beyond the docu- 
nieiit being scanned at a white strip that runs along the 
length of the scan bed underneath die scanner top cover. 
This area of the CCD is called the iifjhl monitor wmdouK 

The light control algorithm for the ScanJet 3c/4c scanner 
has thiee parts. Part one turns on the t>ower to tiie lamp and 
waits until some minimum level of light is detected. Pari two 
tries to balance the output of the red, green, and blue chan- 
nels by acyusting the independent system gains. Part three 
adjusts the power to the lamp u* keep die green output at a 
fixed value during the scan. The tuin>t»se of p^ut one of the 
lamp control is to luni the lamp on and make sure it is fluo- 
rescing at some minimum level, llie goal for the startup 
£dgorithm (part two) is to have the lamp bright enough to 
scan witii low system gains, which helps maximize the signal- 
to-noise ratio. The pun)«*sc of jjari tliree is to maintain the 
huui> at a given level for the entire scan. 

Part one first sets the red, green, and bhu> gains to a low 
leveL Then it turns on the preheaters (the coils at each end 
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of the lamp) for about one second. It then turns on the lamp 
power, which is controlled by a pulse width modulation sig- 
nal, to 20% for 4.5 ms and then lo 8(J%. The first step at 2{)% 
is to help prevent the power supply from ringing. Once tJie 
lamp power is at SiyVa the control loop monitors the lamp 
output using the light monitor window. When the output of 
the lainp reaches or exceed.s the jnininuini tlu^eshold, pait 
tvt^o of the control algorithnt stalls. If tlie tlireshold is never 
reached the contiol loop will time out with an error (after 
about 5 minutes). 

Part two of the algorithm waits about one second for the 
lamp to warm up (at E^Hi power). After the wamiup delay 
the lamp power is lowered to 50% and the red, green, and 
blue system gains are at^justed. In the ScaiLjet 3c/4c there 
are two light monitor windows. One always reads the green 
charmers output, aiid the other reads either the red channel 
or the blue channel The gain contiol loop adjusts the level 
of each system gahi and tries to make the output of the light 
monitor window match a set value called the desired value. 
The window output is checked against the desired value on 
each end"Of-s can-line interruplj or every 4.45 ms. When the 
output of the green light monitor window matches its de- 
sired value (witliin some maigin) 2(}() times in a row, tlie 
gains aie considered stable and die green gain is fixed at its 
current value. If the control loop is tmabie to match the de^ 
sired values by ad,i listing the gains, that is. the gains are at 
maximum or minimum values, it tljnes out. The green gain 
is then fixed at slightly above tlie minimum value or slightly 
below tlte maximum value (to give the red and blue gains 
some margin). 

Once the green gain has been fixed, the control loop switches 
from controlling the gains to controUing the power to the 
lamp. This is part three of tJie light control algorithm. The 
lamp power control loop uses only the green charmel. It 
uses an eight-line mmung average to damp the control loop. 
If the control loop sees a difference of one count for eight 
lines or eight counts for one line betw^een the Ught monitor 
window mid the desired value, it changes die lamp power by 
one count. \\Tien the control switches from the gauis to the 
lamp power, there is a short delay to load the eight line aver- 
age used in tlie lamp power control loop. Mter the short 
delay the output of the green light monitor window is com- 
pared to its desired value, and if they match (\\itliin some 
mai'gin) 200 times in a row, the light is considered stable and 
the scan Is aOowed to start. During this stabilization period 
the red and blue gains are being controlled. Once the light is 
considered stable the red and blue gains are fixed. Tlie con- 
trol loop for the lamp power using the green chartneJ contin- 
ues to operate during the scan. If tlie light falls to match the 
desired output 200 times in a row, die scanner will time out 
with a lamp en'or. Once the scan has started, if the control 
loop is unable to keep the output of the green light monitor 
lAindow within some tolerance of its desired value, a lamp 
error is issued. 

RFI and ESD Design 

Tlie ScanJet 3c/4c color seamier was a challenging design 
with respect to RFI (radio frequency Interference) and ESD 
(electi'ostatic discharge). To begin with, the mechanical 
design didn't lend itself to stellar RFI and BSD performance. 
In an attenipt lo lower cost and weighty the design specified 
a plastic chassis instead of a sheet-metal chassis. Secondly, 



the design spread key electrical systems tiiroughout the 
scanner. For example, the controller board was posirioned 
in the lower rear of the product. The controller board clock 
is deri% ed from a *J(i-MIIz cni^stal oscillaton It generates ttie 
CCD clocks, motor control signals, and lamp control signals, 
processes all of the image data, and controls the SCSI inter- 
face. It also controls the optional automatic document feeder 
or the optional transparency adapter. Not only is the control- 
ler botU"d a source of a lot of RF energ^\ it also has multiple 
interconnections that increase the difficulty of containing 
that RF energy. The controUer boaid comiects to the power 
supply, to tlie carriage, to tlrie SCSI interface, and to any 
optional accessorj^ 

Another key electrical system is the power supply assent bly 
Besides generating + 5V, +24V, + 12\'; and - 12V, the power 
supply assembly also contains the lamp and motor drivers. It 
has a total of tive cable connections including the ac power 
cord, the dc power cal)le to the controller board, tlie lamp 
cable, the motor cable, and the LED power-on indicator 
cable (see Fig. 11), 

The tliird key electrical system is the can-iage, which has 
characteristics that dominate die scanner's basic EMC (elec- 
tromagneric compatibiiity) performance. The carriage Ls a 
metal casting that rides on two steel guide rotis. Tlie steel 
guide rods aie held in place by a sheet -metal plate in the 
rear and by the plastic chassis in tlie front. A fluorescent 
lamp is mounted on the carriage and is connected through 
its own dedicated cable, the lamp cable, to the lamp driver 
in the power supply. The lamp cable is about 15 inches long 
and travels along the right side of the scanner as die cmiiage 
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mo\^es under the glass window. The imaging flex circuit is a 
two-Layer circmt thai is \\Tapped around the outside of the 
CCD and is connected through the carriage cable to the con- 
tmUen It is located in the left rear of the carriage. The car- 
riage cable is a single-layer unshielded flexible cable that 
carries CCD clocks, which can run at speeds over 1 MHz, 
to tlie Lmaging circuit from the controller board. This cable 
also returns the resulting analog image data. The carriage 
cable, which is about 25 inches long, travels along the left 
side of the scanner as the carriage is in motion (see Fig. 11). 

The carriage Is a source of enejrg>* frt>m the imaging cirt^uit. 
It is also an antenna whose electrical lengtJi changes with 
the position of th^ carriage. At least three different electrical 
structures change as the carriage mo\es from the back of 
the scanner to the front. These include the carriage cable^ 
the lamp cable, and the current path tlirougli the steel guide 
rods and the carriage. Because of this dviiamic antenna 
stnicture. the radiating efficiency for any specific frequency 
vnii be optimized at one correspondiiTg specific position of 
the carriage over its range of travel One can think of it as a 
'*self-tuning'' antenna. Typical RFI control approaches that 
merely retune energi^' from one frequency to ai\other simply 
do not work because the new frequency to which the RF 
energy is shifted will just coiTcspond to a different carriage 
position at which the antenna efficiency is optimized for 
that frequency. 

A number of RFI suppression techniques were considered. 
Putting a Faraday cage aiomid tJie whole scanner was. of 
course, impossible because the top needed to be glass. Trying 
to enclose all the electronics and shield all of the cables also 
proved futile. Enclosing the controller board onJy seemed to 
make things worse. Lsing power and groimd islands rlidn't 
help. Ferriles didn't seem to have a lot of impact, and extrap- 
olating their performance, we estimated that RFI might 0!ily 
decrease by 5 cLB if tiie box were completely filled with fer- 
rite. Using capacitors to roll off clock or clock-like signals 
only seemed to increase emissions below 300 MHz. 

We decided that the best approach to keeping RFI emissions 
down was to reduce all possible sources as much as possible. 
We needed to minimize the energy that got onto the carriage 
structure, because any energj^' that got tbere would be ra- 
diated efficiently at some point in tlie can1age*s travel. We 
began to ^work on some new^ approaches that were guided 
by theory and that we later confimied with experiment. 
First of all, we revisited the equation that describes the radi- 
ation from a ctirrent loop. Because this radiation is propor- 
tional to the product of the frequency squared, the current, 
and the loop area, we tried to minimize the areas of ciurent 
loops and to minimize the ciureni in those circuits witli 
series impedance. Because we did not w^ant energy traveling 
onto the self-timing ^mtemia, we puiposely tried to mismatch 
cable impedances so thai most of tlie energy' w^oidd be re- 
flected back onto the controller board rattier than traveling 
out onto the carriage cable. To do Uiis, grounding and sliield- 
ing needed to be minimizerL This meant doing things that 
were jusi the opposite of what would normally be done, 
instead of routing the carriage cable close to metals it was 
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Fig. IZ. Diode cotmection far ESD and RFI suppression. 

raised away from any metal to increase its effective trans- 
mission line impedance. Although the carriage cable became 
a better antemia, far less high-frequency energy was able to 
get onto that antenna because of the impedance mismatch, 

ESD also required an unusual approach* Initially the scanner 
was highly susceptible to static discharges. An air discharge 
of only 1 kX wouid usually cause the SCSI bus to hang even 
if there was no data transfer in progress- This problem was 
idtimately improved by over an order of magnitude by the 
inclusion of a part affectionately knowii as the BMP or big 
metai plate. The BMP is simply the flat metal plate that is 
affixed to the bottom of the scanner Its exact physical di- 
n^ensions turn out to be relatively imimportant because it 
doesn't perfonn its function througli any shielding or plane 
imaging phenomenon. It is attached to the SCSI cable shield 
and merely senses as a huge charge sink. Tlie BMP could be 
comiected to the SCSI shield without regard to three-dimen- 
sional position and it would always improve the ESD air 
discharge perforniance to over 10 kV, even wiiile data vvas 
being transferred over the SCSI interface. 

The ScanJet 3c/4c also inspired an interesting solution to a 
common ESD/RFI problem. Often, different methods of con- 
nectirvg the chassis to dc ground wi!l have different effects 
on RFI and ESD. In the ScanJet 3c. if the chassis was con- 
nected directiy to dc ground at the SCSI coiuiectors, ESD 
performance was improved. However^ if chassis groimd 
w^asn't connected at all to dc groimd except in the power 
supply RFI was improved. In the end, by connecting chassis 
ground to dc ground through parallel diodes oriented in 
opposite directions (see Fig. 12), good performance for both 
HFI and ESD w^as achieved. 
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Building Evolvable Systems: 
The ORBlite Project 

One critical requirement that HP has learned over the years from building 
large systems is the need for the system and its components to be able 
to evolve over time. A distributed object communication framework Is 
described that supports piecewise evolution of components, interfaces, 
communication protocols, and APIs and the integration of legacy 
components. 

by Keith E, Moore and Evan R. Kirslienbauni 



Hewlett-Packard has been building distributed and parallel 
systems for over two decades. Our experience in building 
manufacturing test systems, medical information systems, 
patient monitoring systems, and network management sys- 
tems has exposed several requirements of system and com- 
ponent design that have historically been recognized only 
after a syslein ha.s been deployed. The most critical of these 
requirements (especially for systems wilh any longe\ity} is 
tiie need for the system and system components to be able 
to evolve over time. 

The OKBlite distributed object communication infrastructure 
was tiesigned to meet this requirement and lias been used 
successfully across IIP to build systems that have evolved 
along several dimensions. The ORBlite framework supports 
the piecewise evolution of components, interfaces, commu- 
nication protocols, and even progratuming AJ^ls. This piece- 
wise evohttion enables the integration of legacy components 
and the introdnction of new features, protocols, aiid compo- 
nents without requiring other components to he updated, 
ported, or rei^Titten. 

A vertical slice through tiie ORBlite framework forms the 
basis of HP's ORB Plus product, a strict implementaiion of 
the CORBA 2.0 standaid. 

The Problem of EvolvabiEty 

By definition, a distril^uled system is one that contains com- 
ponents thai need to comnimucate with one another. h\ most 
practical systems, however, many of these components wUl 
not be created from scratch. Components tend to have long 
lifetimes, be shared across systems, and be written by differ- 
ent developers, at different times, in different programming 
languages, with different tooLs, hi addition, systems are not 
static — 3X\y large-scale system vtill have components that 
must be updated, aiid new components and capabilities will 
be added to the system at different stages in its lifetime. Tlie 
choice of platfonn, the level of available technologj^ kmd 
current fashion in the progrannning comnumity all conspire 
to create what is typically an integration and evolution 
nightmare. 



The most common solution to this problem is to attempt to 
avoid it by declanng that all components in the system wiD 
be designed to a single distributed progiaminuig niodel and 
wili use its underlying conununication protocol This tends 
not to work well for several reasons. First, by the time this 
decision is reached, which may be quite early in the Life cycle 
of tills system, tliere may already be existinj^ components 
developers desire to use, but which do not support the se- 
lected model or protocol Second, because of the availability 
of support for Uie model, the choice of niodel and protocol 
may severely restrict other choices, sucti as the language in 
which a component is to be wrilien or the platfonu on which 
it is to be Implemented, 

Finally, such choices tend to be made in the t>eyef that the 
idtimate model and protocol have finally been found, or at 
least that the cunent choice is sufficiently llexible to incor- 
porate any future changes. This belief has historically been 
discovered to be imfoundeci, and there does not appear to 
be a reason to believe that t he situation has changed. Invari- 
ably, a small mimber of years down the road (and often well 
within the life of the existing system), a new **latest-and- 
greatest'' model is invented. When this happens, the system s 
owner is faced with the choice of either adliering to the old 
model, which may leave the system unable to conmiunicate 
i^ith other systems and restrict tJic capabihties of new com- 
ponents, or upgrading the entire system to tJie new model 
Tills is always an expensive option and may in fact be intrac- 
table (e,g.^ one HP test system contains an investment of 
over 200 person-years in legacy source code) or even impos- 
sible (e.g., when the source code for a component is sunply 
not available). 

An alternative solution accepts the fact tiiat a component or 
set of components may not speak die mandated ''common 
protocof and instead provides prox^ senices (protocol 
wrappers or gateways) between the coimiiunicaiian proto- 
cols. Under this schenie. ihe conmumication is fn^t sent to 
the gateway which translates it into the nonstand^u'd proto- 
col and forwards it on to the component* This technique 
t>pically gives rise to tlie following issues: 
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Typical CauSB 
Message forwarding 

Multiple in-memor>' message 
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different communications 
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communication semantics. At the same time, new program- 
ming models are frequently developed. These models are 
attractive because of their ^plicabilit>' to a particular appli- 
cation, because of their familiaTity to progi^mmers on a 
particular platform, or because they are merely in fashion or 
in corporate favor. It must be possible to tntplement compo- 
nents to a new model or a new version of an existing model 
without limiting the choice of protocols to be used under- 
neath. Ii must also be possible to do so %vitliout sacrificing 
interoperability with existing components written to other 
models or other verelons of the same model (ex'en when 
those components wdll reside in the same address space). 



It is templing to think ll>at the problem of e\^ival>ility is 
merely a temporary' condition caused by the recent explosion 
in the number of protocols (and thin^ will stabilize soon) or 
tiiat the problem is just aji artifact of poor design in legacy' 
components (and won*l be so bad next time). It appears, 
however, that this problem of protocol evolution is intrinsic 
in building practical distributed systems. There will always 
be protocols that are claime<l to be belter, domain-specific 
motivations to use them, and legacy components and proto- 
cols that must be supported. Indeed, we consider it a truism 
that nearly any real distributed system will l\ave at least tiure 
models: those of legacy components, the current standard, 
and tiie emerging latest -and-greatest model. Tlte contents of 
these categories shift witli time — today s applications and 
standard protocols will be tomorrow's legacy 

Dimensions of Evolution 

Tlie ORBUte aichitectme is concerned with multiple dimen- 
sions of evolution. 

Evolution of Component Interface. A components interface 
may evolve to support new features. The danger is that this 
evolution will ret|uire all clients of the component to be up- 
dated. For reasons cited in Ihe pre\iotts section, there must 
be a mechanism whereby old chents can continue to use the 
old interface and new clients can take advantage of the new 
features. 

Evolution of Component Implementation. A componenrs imple- 
HK^rUalior^ may evolve iiuk^pt^ndently of the rest of the sys- 
tem This may include the relocation of a component to a 
new hardware platform or the reimplementation of a com- 
ponent in a new progi amming language. There nmst be a 
mechanism that insulates other components from these 
changes in the implementation yet maintains the semantic 
guarantees promised by the interface. 

Evolution of Intercomponent Protocol. It is generally intractable 
to choose a single conmuuiication protocol for all compo- 
nents in ihe system. Different protocols may be more atttac- 
tive because of their peifomiance, availability, security and 
suitability to the applit:atit)n s needs. Eacli conununicaiion 
protocol has its own model of component location, compo- 
nent binding, and often data and parameter representation. 
It must he possible to change or add communication proto- 
cols without rendering existing components inaccessible. 

Evolution of Intercomponent Commufiication Model. Tiie pto 
gi^anuning models usihI to perform uiterccjmponcnl conunu- 
nication continue to evolve. They change over time to sup- 
port communication of riew tyjjes of data ajid new version 



Contribution of Distributed Object Systems 

Distributed object systems such as the Object Management 
Group s C(;)RBA (Conunon Object Request Broker Architec- 
ture)^ - and Micros*>fts* OLE (Object Lij^king and Embed- 
ding),'^ like the reniote procedure call models that preceded 
them, address the issue of protocol evcjlution to a degree by 
separating the programming model from the details of the 
mi deriving j^rotocol used to implement tiie conmiunication. 
Tliey do tftis by introducing a declai-ative Interface Definition 
Language (IDL) and a crompiier that generates code that 
transforms the protocol-neutral API to the particular proto- 
col supported by the niodel (see Fig. 1). As the protocol 
changes or new protocols become available, the compiler 
can be ut>dated to generate new pioiocol adapters to track 
tlie protocols evolution. These adapters are shown as stubs 
and skeletons in Pig, L 

Another benefit of IDL is that it forces each components 
interface to be documented iuid decouples a component's 
interface from its implementaiioji. This allows an implemen- 
tation to be updated without affecting Uie programming API 
of clients and sinipliftes the j>ai'allel development of multiple 
components. 

In CORBA and 01^, interfaces are reflecnve^a client can 
ask an implementation objetH whether it supports a particu- 
lar interiacc." t =sing this dyiumiic mechanism, a client can 
be insiilatcHl from interface and implementation changes. 
Clients familiar with a new interface (or a new 

' In CDHBA C++ thts fs a (tyflamic _ni!TrtiwtJ mecharnfm. (n OLE i! is the JUnknowrjiiQuervlnTer' 
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of an existing interface) ask ahour i1, while old clients 
restxict themselves to using the old interface. 

While such systems abstract the choice of communication 
protocol, none addresses the situation in which a system 
needs to be composed of components that cannot all share 
a single protocol or a single version of ii protocol. ^- CORBA 
anc! OLE have each defined a protocol that they assert all 
components v^ill eventually adopt. For reasons cited above, 
we feel tliat each is merely adding yet another (incompatible) 
protocol to the mix — a protocol that will continue to evolve. 

Key Contributions of ORBlite 

The OH Elite distributed object-oriented communication 
framework was designed with these concerns in mind. It 
takes the protocol abstraction ]>ro\1ded by IDL a step fur- 
ther by allowing a single component to be accessed and to 
communicate over multiple protocols and multiple versions 
of the same protocol, simultaneously and Iransparently. 
Centered around the notion of the declarative interiace, 
OEBlite also provides for different compoiients to be written 
to different models, even when the components reside in the 
same process. The result is that programmers are presented 
with the illusion of Ihe entire system adhering to their pro- 
cessing model regardless of whether tliis is tJue or in fact 
whether Uie component at the other end is even implemented 
using the ORBlite framework. It further enforces the notion 
that programming models and protocols have no knowledge 
of one another with respect to either existence or implemen- 
tation, allowing tlie programmer complete freedom to unx 
and match. 

ORBlite departs from the traditional client/ser\'er model by 
treating caller (client) and target (sen erj as merely roles 
relative to a particular call. Any process can contain objects 
tliat act as both callers and targets at different times or e%^en 
sinuiltimeously Thus, ORBlite is fmidamentally a peer-to- 
peer niodel even though a jjanicidar system may elect to 
follow a strict client/server distinction. 

' The tarm proiocol fn this arr^cie refers lo mora than just the transport pnDlBcof For exampta, 
the OCE protocol supports iriijltipte stnng-binding handles so that objects can be accessible 
□ver connactionless and connection-based transports. However, programs basad on the DCE 
RPC model cannot transparently communicate with piograms based on the ONC flPC model 



The main goal of the framework is to pro\ide an efficient, 
thread-safe comuiunicatiou substrate that allows systems 
to be composed of components whose protocols, language 
mappings (i.e.* object models), implementations, chents, 
interiaceSi and even interface definirion languages can 
evolve independently over time. It must he possible ftjr pro- 
tocols to evolve or be added without requiring recompilarion 
of components, for object models to evolve without obsolet- 
ing existing components (or existing protocols), aiul for 
legacy components to be integiated without requtiing reen- 
gineering. The reality of systems development is that com- 
ponents have different owiiers, different lifetimes, and dif- 
ferent evolutionary time franies. 

One further contribution of the ORBlite framework is that it 
treats local and remote objects identically. In most current 
systems, the sviitax for a call to a remote object is quite dif- 
ferent from a call to one located in the same process. As a 
result, once code has been written with the assimiption tJiat 
•d particular object is local or remote, this decision becomes 
difficult to change. ORBlite, by contrast, encoiurages tlie 
programmer to talk in temis of distnbu table refereywes (i.e. 
references to objects that may be locat or remote) j even 
when the referenced object is believed at coding time to be 
coresident. Application code that uses a distributable refer- 
ence will Hill need to be changed if the refer en ced object is 
later moved to a remote process. Tlie framew^ork provides 
extremely efficient dispatching for calls when the object is 
detected to be coresident. The use of distributable refer- 
ences allows the assignment of objects to processes to be 
delayed weU past coding time and to be ac^justed based on 
perforiTiance or other requirements. 

The ORBlite Communication Framework 

The ORBlite communication framework contains a core aiid 
dn-ee key abstraction layers: tiie language niapi)ing abstrac- 
tion layer the protocol abstraction layer, and the thread 
abstraction layer (see Pig. 2). The core is responsible for 
beha\ior that is not specific to any particular protocol or 
language mapping. This includes tlie management of object 
references and tlie lifetime of target implementations, the 
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selection of the protocol to use for a particular call, and the 
base data types used by tiie protocols and the language map- 
ping to communicate. 

Language Mapping Abstraetioii Layer 

This layer is designed to support ev^olution of the program- 
ming model presented to the application. Using the language 
mapping abstraction layer each component \iews the rest 
of tJie system as if ail other components (mcluding legacy 
components) followed the same programming model. An 
OLE component, for example, news remote CORBA eonipo- 
nents as if they were OLE components^ and a CORBA com- 
ponent views remote OLE components as if they were 
CORBA components."^ This abstraction layer allows compo- 
nents to follow multiple programming models even when 
the components are located in the same address space. 

Protocol Abstraction Layer 

This abstraction layer is designed to support the evolution 
of protocols and the choice of protocol sets a\mlable in a 
particular system. In addllion, it decouples the in-memor>^ 
representation pxpecred by a panicular language mapping 
from die protocol used to conxmunicate between components 
on a given call. For example, implementations of DCE RFC 
assume that the in-memor^' image for a structm^e has a par- 
ticulai" memor>" aligmiient and member ordering. ONC RFC, 
on the otlier hand, has a different assumption about how 
memory^ should be layed oui.'^-^ The protocol abstraction 
layer allows a given language mapping to transparently 
satisfy both without restricting its oiMi layout decisions. 

The protocol abstraction layer provides several features: 

• Support for multiple simultaneous communication 
protocols — services can be shared across communi carlo !i 
protocols and components can interact with objects simul- 
taneously over multiple protocols. 

• Support for trai^sparent protocol replacement — one proto- 
col can be replaced with anotiier protocol without any 
change to application code. Available protocols are declared 
at link time or are dynamically loaded. No recompUation is 
necessary to change the available protocol set. 

• Support for legacy integration—the framework does not 
need to be on both sides of the communication channel 
Each protocol has full control over message representation, 
enabling a protocol to be used lo communicate with non- 
OHBlite components, 

• Support for multiple in-memory data representations — 
applications can choose the in-memory representation 
of data structures without incurring copy penalties from 
the protocols. 

Thread Abstraction Layer 

This layer is designed to provide a portability layer such that 
components can be w^dtten to be independent of platfonu- 
specific tlureaduig mechanisms. The thread abstraction layer 
also serves to coordinate the concurrency requirements of 
tlie various protocol stacks. Wien a protocol can be written 
in terms of the thread abstraction layer, it can coexist with 
other communication protocols in the same process. AJl 
parts of the ORBlite framework are written in a thread-safe 

• Tm mappsrhg bftween CQBBA and OLE was standard^sd try OMG and is detiiifd in 
neferenca 3 
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Fig. 3. The pieces involved in a distributed call 

and tliread aware manner The framework manages object 
iifetiines to ensure tliat multiple threads can be exploited 
and simultaneous cMls can be executing safely in the infra- 
structure and in each object 

These three abstraction laj-ers are strongly interrelated. A 
protocol that obeys the protocol abstraction layer v^ill typi- 
cally use the language mapping absnaction layer to marshal 
and immarshal data structures. A language mapping, such as 
the OMG C++ mapping, will in turn use the protocol abstrac- 
tion layer to aOow the protocol to marshal the stnictm*e in 
tlie protocols preferred representation. 

Conceptual (H^erview of an ORBlite Call 

In ORBlite. there are six msyor pieces uwolved in a distrib- 
uted call. These pieces are showm in Fig, S. In systems 
that include legacy components, two of these pie<*es might 
be pmely conceptual. A legacy sender nught nor have a dis- 
cernible skeleton or an identifiable implementation, yet ^ill 
honor tl>e wii'e protocol. Likewise, a legacy client may not 
have a real stub. 

The ORBlite model is similar to the CORBA and OLE models, 
except that in ORBlite an IDL compiler, for a given language 
mapping, emits stubs, skeletons, and tvpes that are protocol - 
neutral. ORBlite further allows the caller and stub to follow 
a different language mapping from the skeleton and imple- 
mentation. 

Stub. The stub is responsible for timiing a 
client'Side, language-mapping-specific call of 
the form:** 






result e object * foo(a,brC) ; 

into the protocol-neutral fomi: 

ORBlite :: apply (object, '^foo"/ arglifltj ,» 

EssetttiaJly, the stub is saying to the ORBhte core^ "invoke 
the method named "foo" on the implementation associated 
witli object asing tiie list of arguments in arglist" 

Skeleton, The skeleton is primarily responsible 
for the reciprocal role of turrung a call of the 
form: 

OHBl it : s apply { ob j ect , " foo" , argliet ) ; 

back into a call of the form: 

result = impl,foo(a,b,c) ; 

Tlie stub can be viewed as the constructor of a generic call 
frame. The skeleton can be viewed as a call-frame dispatcher. 

■ The examples hsr& usi C++ svntax The actual cail ^iB^ is a prapenv of the languagt 
mapping Also, nm that the internaE calfs descrifaad hare irave b&en simprifisd 
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Traiismittable Types. A language mapping 
de lines one or more in-memoiy data rep- 
resentations or classes for each type 
(e.g., structure, union, interface, any. " etc.) descnbable In its 
IDL. For such data to be piissed to a protocol, it must inherit 
from an ORBiiie-pro\iiled b^ise class TxType. Such classes iire 
callL*d ti-ajismUtaUe lyptfs and support methods that allow 
protocols to request their instances to inarshul themselves 
or to miinarskal tbenxselves from a marshalling stream."^ 
Occasionally, a language mapping may have a specification 
that precludes the ty]3es presenteti to the prugrainnier from 
inheriting from TxType. In sucJi cases, tiie IDL compiler often 
emits parallel transmittable classes that wrap the user- 
visible classes. These parallel classes are the ones presented 
to the core or to I lie protocols. 

By convention J the marshalling niethods are inipleniented in 
temis of requests on the streani to marshal the instance's 
immediate subcomponents. As an example, an object repre- 
senting the mapping of an IDL sequence will marshal itself 
by first requesting the marshalling of its current length and 
then request in j^ the marshallhig of each of its elements. 
ORBUte contau^s abstract transmittal)) e base classes for each 
of the types specifiable in CORBA IDL, which implement the 
canonical marshalling behavior. Thus, the classes deJTnetl by 
a language jnapping typically provide ojily metJiods that 
make a reference to or marshal the subcomponents 

Wlien a protocols marshaUmg stream receives an instance 
of a transmittaljle type, il typically responds by simply 
tunung around and asking that instance to marshal itselL 
Occasionally, however, a protocol may have special require- 
ments for the wire representation (as with DCE's padding 
rei|uirenients for structures). Transmittable types pro\ide 
type-safe accessors (foreshadowing C++'s recent dynamfc_cast(} 
mechanism) wliieh allow a marshalhng stJ'eam to ask, for 
example, "Are you a structure?/' and take action accord- 
ingly, often calling the transmittable type*s subcomponent 
rnarshalhng methods directly. 

The marshalling capability also provides transmittable types 
with the ability to convert from one language mappings in- 
memory representation to another's (or betw^een a single 
language rnapphig's distinct in-memor>* representations for 
the same type). As long as the tw^o data XjpeiS assen that 
they represent the same external IDL type, they can use a 
highly optimized in-memory* marshalling stream to perform 
the conv^ersion widi the source object marshallmg and tlie 
sink ujmiarshalling. 

Local Bypass Optimization, ^lien the stub 
and the skeleton exist in the same pro- 
cess sxjace, the stub can directly inv^oke 
the skeleton's metliods and byi>ass the 
transformation To ;md from the apply! I 
call. In this case, the ctiU: 

result = object » foo{a,b| c) ; 



' A sBlf -describing type ttiat tan holdan instance nf any IDL-dBscriljahle tvpe. 

' Marsha I Sing is the process of serializing a data sTmciure into a buffer or pnto a communica- 
Tian stream such that the tesuiting data stream is sufficient to recreate or mitjalize an equiv- 
alent object UntnarshaEling is the opposite process ^ reading Ihs stream and cfeaimg or 
initializing Itiecbjefl 





is directly forwarded through the skeleton using 
result = iiiipl.£ooCa,b, c} ; 

Note thai the signatures for these two calL^ do not need to 
be identical. 

j\n implementation object can disable this optimisation. This 
is useful when aii object v^ishes to ensure that a protocol 
bas an oppoitunlty to service eveiy^ invocation, even those 
that arc local. Certam loggmg, higli-availabilityj and release- 
to-release binary compatibihty mechanisms ref|uire tins 
form of protocol inte^'Cntion, even for tlie local C3ts£^. 

Wlien the stub and skeleton reside in the sanie process but 
follow different language tnappings, I iie Ht lib may not know 
the target implementation objects calling conventions, or 
the argument data may not be in the appropriate form* When 
this happens, the local bypass is not taken. Instead, the call 
Is routed thiough the protocol abstraction layer, which will 
use a very efficient local procedure call (LPC) protocol. This 
protocol behaves like a full RPC protocol (see below) » but 
instead of marshalling its argument list, it merely tells the 
arguments to convert themselves from the caller's fonnat to 
the target's. 

RPC Protocot The RPC 
protocol is prin^aiily 
responsible for imple- 
menting a distributed 
applyll caU. It works in 
cooperation with the trajisnvittable tj-pes to migrate a call 
frame from one process space to another, OliBlitc does not 
require that tlie protocol actually t>e an liPC protocol, only 
that it be capable of presenting the semantics of a thread- 
safe distributed applyO caU. As>TichroTtous and synchronous 
protocols iu e supported, and it is common for more than 
one protocol to be simulttmcously executing in the same 
process. The protocol may also be merely an adapter which 
is only capable of producing the wire protocol rcquured 
for a particular remote interface but is not a full RPC imple- 
rtientation. 

The separation between the trmismiUable types' marsh oi- 
lers and the RPC protocol means that transmittable types 
can be reused across different RPC protocols (see Fig. 4), 
An additional benefit is that adding a new custom protocol 
is fairly striiightforward because almost all of the complex 
mai-shalhng is bajKlleil outside of the protocol layer. 

All RPC protocols have the sanie shape, meaning that each 
protocol obeys the protocol abstraction layer There are 
weil-defmed interlaces for how a stub mteracts with the 
protocol how the protocol interacts ^ith the marshallers, 
and how the protocol interacts with the skeleton. 

Tfiese interfaces are, however. logically private in tliat they 
ai-e not du'ectly exposefl tt> the cOent or to the implemenia- 
tion. Keeping these interfaces pri\ ate means that the s^'Stem 
can dynamically choose, based upon a vEuiety of variables, 
which protocol should be used to connect a particular client 
to a pailicular implementation for a particular call. Examples 
of vailables that may affect protocol selection woukl be the 
protocol's estimate of the time needed to buid to the imple- 
mentation, a protocols roimd4rip-time estimate for executing 
ati apply( I call, the security required on the conmnaticationj 
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Fig. 4. Alternate RW i>rotn(nls. 

whether the channel should be rebound on error, or the 
iatency allowed for die trail invocation. 

Internal Structure of an RPC Protocol. Only the external inter- 
laees lor ilie RFC pruiovoLs aie defined by ORBlite, The 
internal structure may vmy considerably between protocols. 
ORBlite makes no statement on whether a protocol is con- 
nection-based or connectionless, which marshalling format 
is used (NDR, XDR, ASCII, etc,), wliether the protocol repre- 
sents ciata in hig-entliun or little-endian formal, t>r even what 
physical medium is used by the underlying {■ominumcation 
mechanism. Iri general, however, protocols will have the 
tiiree ni^or components shovm in Fig. 5: 

• Tlie RFC C'lient implements the client side of the 3pply( ) call 
and is responsible for locating tlie target's implementation, 

• The primitive maishallers support ti\e najis mission and 
reception of primitive data lyijes in a protocol-specific 
mature r. 

• The RFC Server is respoi\sibIe for receiving tlie call over the 
wire, using the ORBlite core to find the skeleton associated 
with the target of the invocation and forwarding the RFC 
Client's applyi I call to the target skeleton. 

Logical Call Flow 

Given these pieces of the puzzle, the logical flow of control 
for a remote method invocation is shown in Fig, 6. 

Step 1. The caller executes the method f(a.h,c) on the stub 
object. 

Step 2. The stub creates an arglist and calls the RPC Client's 
appiv( \ function. 

Step 3. If necessaiy, the RFC Client binds wiUi the target's 
RPC Sewer using a protocol-specific mechanism. 

Step 4. The RPC Client marshals the identifier for the target 
skeleton and then marshals the name of the operation to 
perfonti. 



Step 5. The RFC Client raarshals an identifier for the target 
skeleton, then marshals the name of the operaHon to per- 
form, and finally tells the arglfst lo marshal itself (handing in 
the transport's primitive marshallers). The arglisi will use its 
transport independent marshallers to turn composite data 
structures into primiti\'es which can be marshalled using the 
traiisport s primitive marshallers. 

Step 6. The RPC Server unmarshals the identifier for the 
tai^et skeleton and then imntarshals tlie name of the opera- 
tion to perform. 

Step 7. The RFC Sender then upcalls Ihe skeleton to gel the 
serv'er-side arglist for the specified operation. This upcall is a 
critical component in decoupling the language API from the 
underlying protocol. Without this upcalh the RPC Sener 
component would have lo know rJie memoiy^ format that the 
skeleton is anticipating and therefore would be tied to a 
particulai" niemorj^ iitapping. 

Step 8. The arglist returned from the upcall, which is opera- 
tion-specific, is told to unniiaishal its argimients. Each ai"gu- 
nienr is a transmittable t>^je and will use the protocol inde- 
pendent unniarshallers to construct the arglist contents from 
primitives immarshaJled using the protocol's unmarshalhng 
stream. 

Step 9. The skeleton is upcalled to apply the unmarshalled 
arglist to the desired operation. 

Step 10. The skeleton takes apart the arglist and invokes the 
actual method on the iinplenientation.Wlien the call on the 
skeleton completes, the RPC Serv^er will cisk tite arglist to 
marshal its output paiameters back to the client process. 
The RFC Client will unmarshai the output pai^netei-s and 
the stub will return the values back to the caller 
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Fig* 5* The major iransport comi>onants jisjjoeiated with protocols. 
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Dimeiisiaits of Evolvability 

111 This serllnn we disfuss how ihe ORBlile fnin^^^wnrk 
addresses the vaiioiis types of evolvability. 

Evolution of Object. Implementation 

ORBlite uses the IDL specification mid tJie language map- 
pings denned by TORBA ^ind OLE to decouple an objeci's 
|jui)lenteii(;iiion IVoiu Us intetiace. hi HiLs manner, lui object's 
implementation can Ije ujjdaled wilhonl alTecting miy other 
pajt of the system providetl that the interface is considered 
to specify not only syntax but also semantics and beha\ior. 

ORBhte is not tied to a particulai" IDL or even the set of tlata 
types descrihable by a paiticular IDL. ORBhte requires tliat 
isomorphic pails of diffeieni [DLs l>e mapperi ro the same 
base t>ije constiaicts. but model mid IDL designers me free 
to expenment with extensions. Such extensions may, of 
course, impact inter operability. For mstanee. a sender whose 
interface uses a non-CORBA IDL ly|)e snrh as an asynchro- 
nous stream camiot easily !>e called by a client w lK)se mixlel 
does not map Litis type. 

Evolution of Object Interface 

hi ORBlite. objects can stippoit multiple interfaces simulta- 
neously, mid the language niapping abstraction layer allows 
clients to mquire of a target object whether tlie target sup- 
ports a partictUar interface (in the OMG CORBA C+-h map- 
Ijing, this is presented as the _narrQwO and is_ail methods and 
in OLE C++ tills is presented as QuerytniarfaceO)* 



If an ORBlite object supports new funrtionality (or changes 
the senumtics behitid an interface) tht^ (object should export 
a new interface. Old chenrs can qner>' for the old interface, 
and new^ clients can queiy for the new one. In this manner, 
the target object can support old clients as well as new 
ciienls. 

Of course, with a strongly typed object model such as 
CORBA, such dyiuiiTiic queries are often turn ecessaiy since 
the received object reference may alreatty luive been re- 
ceived as a strongly typed reference UiWw new interface. 

Evolution of Programming Model 
From the standpomt of evolution, ttiere ^ire iwo jtspects of 
model evolution that must be anticipated: stippoil foi^ the 
iiuroduction of new data types and support for new imple- 
mentations of existmg data ty|jes. 

Evotution of Language Mapping Types^ Tlie ORBhte frantework 
defines a set of l>asic data t\^ies from which die tninsmit- 
lable types usetl by each language mappijig me derived. Ai 
the root of the tree is an abstract class TxType which reqtiues 
the derived classes to support _marsha!l) and _Ljnmarstiall) 
methods. These metliods t^^ke a primitive marshalling stream 
paiameter sui^plied by the proioi ol beinj^ used for a iiatticu- 
lar call. Framework-prn\1tIed subclasses of this imoI deniie 
mta*e interfaces for each of tlie basic types descrihable by 
CORBA IDL (e,g.. structures, sequences » or emmierarions). 
Tfiese subclasses i:iro\ide default marshalling beha%1or in 
terms of (abstract) methotls for marshallii^g and mmiarshal- 
ling the object's conponents. 
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A Language mapping can ei-oh^e in two different ways. Since 

it is responsible for pronding the actual t>pes iLsed by the 
programmer, it is free to defme and modify- Uieir interfaces 
as emitted by ihe language mapping's n)L compiler. Canoni- 
cally. these types will derive from the ORBlite-provided base 
classes shown in Fig. 7. so an OMG CV+ striKlure or COM 
array will be seen by a protocol as merely a generic struc- 
ture or array, regardless of its inteniaJ represenialicm. 

Note thai there is no requirement that the actual types as 

presented to tlie programmer be ti^msmit table. A language 
mapping merely has to guarantee transmiltat>iiity of the 
data provided to a protcK^oL It bi perfectly acceptable for a 
lajiguage mapping io use a transmirtable wTapper class 
within argumem ILsis and idiosyncratic classes (or even C^+ 
pnniitives or arrays) in ils API. 

Tlie other way I hat a language mapt*ing cim evolve is by 
adding types that are not directly supporte<l by tlie OKBhte 
framework. The OLE mapping, for example, does this to 
create a VARIANT data t>pe. The mapping can choose to inv 
piement the new data type in temis of one of the existing 
tyi>es (for instance, introducing a tree data type for use 
by the application but intemaiiy representing \l using a 
sequenc^e data type) antl subctasHsing from a jirovitletl base. 
Tlie language mapping can also clioose a private representa- 
tion for its contents and derive directly from TjcType. 

An additional attribute of OEBiite that supports a language 
mapping evolution is that the ORBlite framework makes no 
re<juirement that a language mapping have a unique class 
representing a panic tilar IDL type. This alkm s a mapping to 
[ jrovide different representations of a type for different pur- 
poses, h also allows a later version of a language mapping 
to cliange to a new representation for a data type while 
remaining al)Ie to handle the old version's representation. 
For pxiunjile, the ORBhle core uses two dilTeivru uiappings 
for strings: one optlmixed for equality comijarisrjn m\d the 
other for concatenation and modification. To tiie protocols, 
they behave ideniically. 

Evolution o! In-Memorv Representation, There are two key 
issues invcjKcd in iMiwudnj^ thai (he OHBIite core and the 
protocols are decoujslcd from tfie kmguage mapping's data 
tyije representation. The first issue is ensuring that the RFC' 
ClietU can marshal the parameters of a call, and Ihe second 
is ensuring tiiat the RFC Server can unniarshal tlie parame- 
ters without re<juiring excess buffering t)r parameter trans- 
formation. Essentially, we do not want lo have ic? require 
t hat 1 he language mapping translate from a protocors in- 
memorj' data representation to its own. 

The fu^t issue is handled by the transmittable tytJes' mar- 
shallers and accessoi's, which allow a protocol to marshal 



and retrieve composite data ty^p^ without any know^ledge of 
a language nia^sp'mg's in-memory data representation- 

The second issue is more complicated, and is shown as step 

7 in Fig. 6. in which the RFC Ser%-er upcalls the skeleton to 
acquire tlie server-side default argiist. This upi-all allows the 
RFC Server lo offload memcsty niajiagement and in-memoiy 
representation for the incoming arguments to the portion of 
application code that acnially knov^3 the data type that is 
ex|>ecteti. A consequence of this is that thi" RFC Server can 
be reused across language mappings and is if\dependenf of 
the evolution of a particular language mapping. 

The arglist returned from the upcail knows how to unmanihal 
itself. This means that the RFC Server does not need to 
buffer the incoming message and can allow the arglist to un- 
marstial its ccmiponetus directly into the language-ntapping- 
speciiic memor>^ representation. This is sometimes called 
zero-copy unntarshalling. The number of message copies is 
a niiyor performance bottleneck in interprocess me^^ging. 

Some language mappings, such as otu: experimental C++ 
mappings allow aji implementation to override the skeleton's 
default constj-Liction of tlie argiunents. This is topically used 
when the implementation hiis a pailicular memory' represen- 
tation that is more convenient for the appUcation than the 
default representation provided by the language mappuig 
(e.g.* die tree structure mentioned eaiUer). CKerriding the 
construction of the defauk aiguments removes the copy that 
would normally be required to switch representations* A 
language mai)pit^g can use this technique to support featmes 
not, currently fonnd m CORBA or OLE.* 

The upcall is also used for two other features: 
> Checking the per-object and per-methtKl sectirity policies 
* Setting the tliread- dispatch policy (e.g.. thread priority and 

whether a new tliread should be launched when executing 

tJie method). 

A language niaj^pitrg will typically allow the implementation 
to override the skeleton's default responses lo the security 
policy or thread-dispatch mechanism. 

Supporting Protocol Evolution 

The princijjal obsiacte to protocol evolution hi most systems 
is Ihe dependency of application cofle on protocol-specific 
APIs. In ORBhte, there iu*e no references by tiie ORBlite 
core or by any of Ihe language mapjjing components (Le., 
the stub, die skeleton, and the transmittable types) to any 
specific protoc^ol. Given this independence from a speciOc 
protocol, there is no need for \isibility lo the prognunmer. 

■ For msiartcfi. arbitrary grai^, migrat3;b1e objects, of struciuras ttrat support inheriunce. 
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This actually caused n rather interesling problem. It was nol 
passible to just link a protocol into ati OHBlite image as a 
normal C-^+ tibraiy. Since the core sui:»ports multiple proto- 
cols and there aie no referejices by the language mapping or 
tJie core to any protocol, the linker does not have any um e- 
solved s>Tnbols that would pull In a protocol built as a hbrary. 
To overcome \Ms obstacle we Ibrce the protoc;ol to be loaded 
by creating an unresolved reference al link time. 

The protocols of a bystem evolve by dynamically or statically 
linking new protocols (or new versions of old protocols) 
into an ORBlite [jrocess. Updating or adtling a protocol re- 
quires no change to tjie application code, the OKBUte core, 
or any language mapping. 

To add a new^ protocol, the protocol developer derives from 
foui' abstract classes (the RFC Client, the RPC Serv^er, the 
RFC primitive marshallers, and the RPC_lnfo chiss). The 
RPC_lnfQ class regLsiers the protocol with Uie ORBhte core 
and implements tlie brnddcaJI for the protocol. The bindd call 
returns an instance of the RFC Ghent abstract uiterFace that 
wiU be used to issue the applyO call for conmiimi cation with 
a particular virtual process. 

The RFC primitive marshallers will be used during the applyO 
caU to choose die orvtlie-wire representation for tJie argu- 
ments of a call. They are called to nuurshal primitive data, 
such as mtegers and tloating-point niunbers, and are also 
given a chance to handle composite transmittable tj^pes. 
Normal ly, this last call merely hands marshaUing responsi- 
bility t)ack t.(.j the U'ansmittable object, but the protocol can 
tise tliis hook to satisfy special externally mandated padding, 
alignment, or ordering requirements as with DCE RPC's 
alignment requirements for st mcturcs and miioi^. 

Managing Object References and Binding. Fig. 6 depicts tJie 
flow of a met 1 tod invocation tissuming an RFC Client lias 
already been selected. In its simplest form, an RFC Chent is 
selected when a client invokes a method on a stub. U the stub 
is not ^ilrcady bound to a suitable RPC (-lient, the stub asks 
tiie OHBlite infrastructLue to find a protocol that can con- 
nect to the tai*get object associated widi an oljject reference. 
A bomid RPC C-iient can become unsuitable if tiie chent re- 
quires a particular quality of service [such as authentication 
or deadline-based scheduUng). If the RPC Client is not 
suitable, a new RFC Client must be bound or an exception 
raised. 

Each protocol registers wltlt the OKBhte core a unique iden- 
tifier and a binduig inteiface. Each ofjjeci reference contauis 
a set of protocol tags and opaque, protocol-specific address 
information. The tags supplied in the object references are 
used by OKBlite to select a protocol that might be able to 
conMiiunicate with tlie target object. 

If the target object is accessible over multiple protocols (i.e., 
both the client and the server support more tiian one proto- 
col m common) theti the protocol with the best quahty of 
service is selected. The current selection criterion is based 
on a combination of the overhead involved for binding to the 
process associated with the reference plus the overhead for 
invokuig tlie call. .^\ssuming tJie process containutg tlie object 
is activated, most RFC protocols have a 10-ms initial binding 
cost plus a 1-ms round-tnp overhead per call. Protocols that 
can reuse comiections across objects aie generally selecte^l 



in preference to connectionless protocols, wiiich are se- 
lecteii ui preference to protocols dial require comiection 
setup- The actual quality-of-service parameterization can get 
comp heated. A named collection of collocated objects is 
called a virtual process. Fig. 8 show^s the situation in wiiich 
a process has exported two objects A and B in the \irtual 
process VP1234. The \irtual process is accessible over three 
protocols: UOP (Inteniet Inter-ORB Protocol), ONC RPC, 
and the DCE^CIOP (DCE Conmion fnter-ORB Protocol). 

In ORBlite, protocols are encouraged to cache in the object 
reference tlie protocol -specific address of the last known 
location of the virtual process contauiing the object. While 
objects do move, the last knowTi afl dress is often coiTect 
and caching it can improve performance over using an 
external location mechanism. 

Handling Common SaalabilitY Issues. ORBlite was designed to 
suppon vi-ry laige nnmber.s ol Oljjeci references (more than 
100,1^00) wltiiin a single process. To improve the scalability 
of location and perobject memory' overhead, ORBlite pro- 
vades support for protocols that wish t.r> merge per-object 
cache information for objf^f't-'^ located at the same address. 
In this model of object addressing, the address infonnafion 
held in an object reference is partitioned into two parts: an 
address associated witli a \artiial process identifier and an 
object identifier, w hich iuric|uely identifies the object within 
tlie virtual process, hi Fig. 8 the objetts tu^e named A@VF1234 
and B@'\T1234. A client tiiat. ht)lds references to A and H 
can merge the cache infomiation for the virtual process 
\T1234. 

Often tliere are hundreds if not thousands of objects per 
process^ ami therefore, if location inforntation for a protocol 
is based on a virtual process identifier, lf>caliug a single 
object in a process will have the side effect of refreshing 
the address information for alJ other objects at the same 
address- Some protocols w^Hl lose cache uifomiation for 
other protocols as the object referetice is passed between 
processes. Tliis is unfortunate because the cache infornuv 
tion must be recreated Lf the object is to be accessible over 
other protocols. It is higlily recommended that protocol de- 
signers aliow' object references to contain additional opaque 
iid'orniatioii tiiat may be used by otiier protocols. 
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ORHit^ makes no requiremeiit that a protocol use tiie vir- 
tual process abstraction, nor does it diaaie how a protocol 
locoes an object. ORBlite does expect, however, that the 
protocols address information contained in an object refer- 
ence is suflBcient for that protocol to locate and, if necessai>; 
activate the tariget object, 

Supportiitg Legacy Protocols 

In most cases, an object reference is created when an iniple- 
nieniation is registered witln the ORBlite infirastructure. 
UTien such an object reference leaves the process, the 
opaque, protocol-specific address iaformation associated 
with each currently loaded protocol is marshalled along 
with it 

hi the case of legacy componentSt it is likely that ORBlite is 
not in the sen-er process. In this case^ the binding infomia- 
tion for the protocol must be added to the object reference 
via some other me<^haiiism. Such ad hoc object references 
may be created by the iegacy protocol, which obtains ad- 
dressing information through an out^f-band mechanism. 
Alternatively, they may be acquired using normal protocols 
from a special-purpose sen'er which creates the references 
fi-om information kept in system configuration tables. How- 
ever such constructed object refereiices are f)btatned. they 
are indistinguishable from real object references and can 
subsequently be handed around in nomial ORBlite calls. 

When a stub attempts to bind the object reference, the pro- 
tocol tag is mate lied to the protocols supported by tbe chent 
process, If the process s up] j oris the protocol, an RPC Client 
is created that can interpret the request and communicate 
with the non-f JEBlite ser^'cr using the legacy protocol (see 
Kig. 9). 

WTien ORBlite is not on both sides of the communication 
link, the protocol used is referred to as agatewai/ protocoi. 
Note that gateway protocols are not only usefiil for conmiu- 
nicating with legacy senders — an ORBlite process can puL>- 
lish itself on a legacy |>rotocol so that it c£m be called by 
legacy^ non-ORBlitc <:lients. This form of publican ion is espe- 
cially useful when a service needs to be acc;essiijle over both 
old protocols such as DCE RPC and new protocols such as 
HOP 

Supporting Evolution of the ORBlite Core 

In developing and deplo>ing the ORBlite system, it became 
apparent that the tyi>ical owners of language mappings and 
protocols would not be the same as the typical owners of 
the ORBlite core. System developers from entities such as 
divisions building medical systems, test and measurement 




DRBIite Process 



Non-ORBIite Process 



sj^stems* or telecommunication systems were willing to own 
the portion that was particular to their domain, but each 
wanted the rest of the sj^stem to be someone else's responsi- 
bihty 

This meant iliat the core itself needed to be able to e^^ohe 
independently of the language mappings or protocols thai 
plugged into it. It had to be simple to hook new protocols 
and mappings Into old infrastructure and new in&astructure 
had to support old protocols and mappings. 

Hie combination of the language mapping abstraction layer, 
ihe protocol abstjraction layer, and the thread abstraction 
layer has made such independent evolution extremeiy 
straightforward. 

Experience with tlie Framework 

ORBlJte was conceived in December, 1993 to support test and 
measurement systems. These systems contain computers and 
measurement instruments and are used in scientific experi- 
ments, manirfacturing test, imii emironmental measurement. 
Analysis sho%ved that the complexity of constructing the test 
and measurement system was the limiting facior in getting a 
product to market. Existing systems used a number of dif- 
ferent CO nmiuni cation mechanisms, and each component 
tended to have an idiosyncratic (and often undocumentedl 
interface. Witliin HP, systems have used HP-^IB, raw sockets, 
ONC/RPC, SNMR NCS, and NFS. 

At the time, tiiere was a desire to move toward more stable^ 
coniputer-indusrry-standard mechanisms, but it was unclear 
which proposeti standard would win in the long rtni. The 
most likely contenders, CORBA and OLE, were still far from 
being well-specified. As we began publicizing our efforts 
within ME we disc^overed that many otliers were facing a 
similar dilenmia — notably those divisions responsible for 
medical systems and network maj\agement systems, each of 
which had its ow^n set of legacy communication protocols. 

The first version of DHBlite became operational in August 
of 190L It supported tlie HyperDesk 11)170+ tanguage 
mapping*' ^md two connnunicatioi\ protocols: a thread-safe 
distribtition protocol base^l on C')NC KIK\ and a gateway 
protocol desigtTed to c^onnect ORBlite services and clients to 
installed nieflical applications using the HP CareVue 9fK)() 
RPC protocol. Tlie framework was ejrtremely port able, 
thread-safe and reentrant, and because of t he thread ab- 
straction layer, it compiled vtlthout change on both 1 'NIX® 
and Microsoft platfoixtis. It wiis usetl in medicaf test and 
measurement, analytical, financial and teleconmnmi cation 
monitoring applications. 

Over the past two years, dramatic changes have occurred In 
the specifications by OMG and in the OLE implementation 
by Microsoft. OMO has ratified a C+-h language mapping/ 
tw^o new standard ronimnnication pjutcjcols,^ and r*"cenlly 
m) OLE language mapping for t'ORBA.^ In addition. Micro- 
soft has released a beta version of Uie DCOM (Dlsirihute*! 
Component Object Model) protocoi^^ 

In May, 1995, the ORBlite architecture began to make its 
way into external products. MP's Distributed Smalltalk was 
reimplemenied to supptjit the protocol abstraclion layer, 



Fig. 9. I siAg transport gateways. 
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and the ORBlite code* base was transferred to the Chelms- 
ford Systems Software I^boralory lo be turned inro HP ORB 
Pkis aiid released to extenial fustomei-s in April, 1990, HP 
ORB Plus, a strict Inipleinentaiion of CORBA 2,0, needed to 
support the new CMC stiindard C.V+ language mapping^ 
which was previously unsupported by ORBlite. This pointed 
out the need for a woll-detined language mapping abstraction 
Jayer and spiurcd its definition. 

Since the transfer, the mfrastmcture has continued to evolve. 
We have experimented with new protocols to support high 
availability and legacy integration anci oew hmguage map- 
pings to support potential new IDl^ ciaia types and to sim- 
plify the progiammer's job. We are also investigating imple- 
nTenling an einbeddabie version of tlie architeciuie, which 
would have the same externally \isible APIs but would be 
able to run in extremely memoiy-liniitetl environtnents. 
FinaJly. ue lu e looking into the declarat ive specification of 
protocol -neutr^U quality-ol-senlee requiremonls ;md capabil- 
ities. This would assist in selectiug ttie appropriate proto- 
cols to use and in guaranteeing the desired quality of ser- 
vice, where this interpreted to include perfbnnance, 
security, payment, concurrency, imi\ many other dimen- 
sions. Following the ORBlite philosophyj we are attempting 
to design thi.s mechanisni in such a way that the set of avail- 
able qiiality-of-senicG dunensions itsetf can evolve over 
time witiiout impacting existing components. 

The ORBlite infiastnictnre has allowed developers to build 
systems even as the standards evolve, Tlie support of multi- 
ple language mappings, thread-safe distributed object com- 
muuication, and nmltiple protocols has pj'ovided a imifying 
approach to building components and systems across the 
company ► The key issues on the horkon will l>e ensuring that 
the st^Tdm ris from Microsoft, OMG, and others consider 
concurrency, streaming data types, and quality of service 
parameterizat ion. 
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Developing Fusion Objects for 
Instruments 



The successful application of object-oriented technology to real- world 
problenns is a nontrivial task. This is particularty true for developers 
transitioning from nonobject-oriented methods to object-oriented 
methods. Key factors that improve the probability of success in applying 
object-oriented methods are selecting an object-oriented method, 
developing a process definition, and continually improving the process, 

by Antonio A* Dicolen and Jerry J, Liu 



Object-oriented technology is fast approaching mainstream 
status in the software rommunity. Many softi^^are flevelopers 
are interested in becoming objec" I -oriented prac*titionen>. 
Managers, once skeptical of its value, are considering its use 
in their business enterprises. This technology is old enough 
not to be a fad and new enougli lo be recognized by custom- 
ers as tiigh technology. 

Withiii the enibe^lded caniniunity (i.e.. microprocessor- 
basetl instnmientation) at IIP, there is significant interest, in 
adopting object-oriented technology' for the development of 
new products. However, the adopt ion rate of object-oriented 
technology al 1 \V hits been hampered by earlier negative 
experiences. Atttmiptsto use ol>jert<)rienteti tecluiol(>g>' in 
inst.niment.s occun^ed as early as the mid 198Ds. At that time 
the techtiology wa*i in it-s infancy; The metf^wls for employing 
the technology were Inu nature and the development tools 
neces.sary for its efleciive use were rif>nexistent. Application 
of the technology at that time resulted in unmet product 
reciuirements. 

These experiences hindered further developnient using 
object-oriented technology. Object-oriented technotogy 
became sjTionymons with slow speed, high risk, and fiiihire. 
This perception imprinted itself on tlte cutlure of HF di\1- 
sionju usinj; embedded software technology, ft was not until 
the early 1990s thiit this jiercc^ption began to cliat^ge. As 
engineering productivity becanu» mi issue ff>r lUcmagement. 
software reuse* emerged as a ])(>ssitjle solution. With tense as 
a business goal, an object-oriented approach was once again 
considered as a means of achieving that goal. 

l! is important to recognize that reuse and ohject-oriented 
technology' are not s>iionymous since it is possihle to 
achieve reuse without mi object<jriente(i at)pniach. Soft- 
waie math libraries mv a prime example of this fact. This 
type of reuse is called libmry reuse. It Ls the most common 
and the oldest, fomi of softwiire rettse. Generative reuse, 
sucli as that provided by tools like tex tmd yacc, is miother 
form of software reuse, hi geju^raJ these tools use a common 
lmi)letnentation of a state machine ami allow the user lo 
modify its l>ehavior wheji certain states are reached. 



Another tyj^e of reuse is Jramework reuse. Microsoft'^ 

Witult jws' user interface is an example of framework reuse. 
in framework reuse, the tuteraction among the system com- 
ponents is reused in the different implementations of tlie 
system. T!iere may be certain common code components 
that some. l)ut not necessarily all, of the intplementatjons 
use. How^ever. the framework is what all these systems have 
in conmion. Microson foundation classes are an exmnt>le of 
conunon code components. Memi I jars, icon locations, and 
pop-up windows are examples of elements in tJte fraine- 
w^ork. Tlie framework specifies their behaviora and respon- 
sibilities. 

One reuse project based on this aj^iirtjach was a fimiw^^ire 
platfomi for instnmiettts developed at our division. Tlie goal 
w^as to design an object-oriented fimiware fnuuework that 
cou I d be reused for < 1 i ft e re r i f i 1 1 sf n i n i e f k t s . With t h is p roj ec t, 
w^e hoped lo use ot>je( t-orieuted lechriolog^' to i^ddress re- 
use througli framework rease. We c*hf>st^ to use Fusion^ - an 
ot>jectHjriented tuialysis ajxd design methociology developed 
at UP Laboratories, to develot> olu' insinutient framework. 

Iri this article, we Fii\st describe the finnware framework and 
our use of die Fusion process. Next we jjreseni otir addi- 
tions to the analysis phase of the f^isioii process, sue h as 
object idendficaUon and hierjirchical de<'omposiUon, A dis- 
cassion of the modifications to the destgri tJbase of Pulsion 
tlien follows, intiurhng sucii lopicsas ihreadsand t>ai terns. 
We conclude with the lessons we learned using Fusion. 

Firmware Framework 

The new finnware fnuuework is an application framework. 
An application framework jirovides the environment in 
which at (ihection of otjjects collafM)rate. The framework 
tmjvicies the inlVaslniclute liy defining tire interface of the 
abstract classes, tJie interactions ajuong the objects, and 
some instant iable ( otnponerUs. A software component, or 
sinu>ly a coni|>onent^ is an atomic collection of sourct^ code 
tised to achieve a fin u lion. In toimy situatioas, a component 
will have a one-to-one concspondence with a C+-f object. At 
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other times, a component may be made up of multiple 
objects Lmplemeiiteci in C++ or C source code. 

Users of the firmware framework contribute theii- own cus- 
tomized versions of the derived classes for tlieir sj^ecific 
applications. Note that the framework approach is very dif- 
ferent from the txaditional library approach. With the library 
approach, the reusable components are the library routines, 
and users generate the code that invoke these routiiies. With 
tlie framework approach, the reusable artifacts are the al)- 
stractions. It is their relationships to one another, together 
witli the components^ that make up the solution to the 
problem. 

The firmware framework contains a number of application 
objects. These are different kinds of applications that handle 
different kinds of responsibilities. T[\e responsibilities of 
these application tjbjects are well-defined and focused. For 
exajuple, there is a spectrum analyzer application tliai han- 
dles the measuremerU aspects of an instrument a2id also 
generates data, a display application that is responsible for 
formatting display data, and a file system appjicalion that 
knows how to fonnat data for the file system. 

There is always a root application in the system, which is 
responsible for creating and destroying f>ther applications 
and directing inputs to them. Other components of the appli- 
cation framework include the in.stniment network layer and 
the hardwme layen Tlie applications eonmuininate with 
each other \Ta the uistrument network layer. Tlie har<iware 
layer contains the hajTiware dp\ire driver objects, which t he 
applications use dirougli ^i haixiwme resoiucx' manager. Fig. 1 
shows an overview of the firmware frajiiework. 

Appiieation Layers 

An application in the firmware framework is a collection of 
objects orgtmized info three layers: client mterface, mea- 
surement results, and funtlamental infontiation. These layers 
deal with information a! different levels of semantics. The 
semantics at the client interface layer deal with instrument 
functionality while the semantics at the ftmdanienttJ infor- 
mation layer are more related to areiis such as hardware 
control. 

CI rent Interface Laver. Tliis layer represenLs ati abstraction 
containing user selectable par^iineters, the interface for 
setting these parameters, tlie results, and the sequence for 
generating the results. Tims, the client interface layer de- 
fines the features and the capabilities of an application. It 
is responsible for maintaining application state information 
and creating the requested results. This layer also contains 
a collection of application parameter objects that store the 
state of the application, and a dependency manager thai 



manages the parameter limiting and coupling dependencies. 
Tlie dependency manager also triggers events on state 
changes. These state changes cause the selection of the 
correct MeasurementResutt to use to satisfy the user's request. 

Take, for example, a simplified n^ultirneter instnunent. It 
could be an ohmrtieter, a voltmeter, or a current meter. To 
select the voltmeter mode, the instnnnejit softw^are must 
deselect the ohnutieter or cunent meter mode and then se- 
lect die voltmeter mode. Tlie user interface simply turns on 
voltmeter mode. The dependency manager knows that these 
three modes are mutually exclusive and automatically sets 
the cunent meter tuid ohmmeter modes to off. In addition, 
tlie user could set the measured voltage to be the average 
value or the rms (root mean s<|uare) value. This corresponds 
to the selection of a specific MeasLrementResuft that provides 
tlie information the customer is interested in. 

Measurement Result Layer This layer is made up of objects 
deiived from a base class called MeasurementResu It. These 
objects contain the measurement algorithms that specify the 
methods for combining raw data into meaningful data. 

MeasurementResult objects subscribe to and respond to events 
in the cUent interface layer and in other MeasurementResult 
objects. Complex measurement results conl^^un simple Mea- 
surementResult objects. Examples of MeasLrementResult objects 
in an instmment application aj"e SweepMR, MarkerJViR, and Limit- 
LjnelVlR. Tliese could be he measured values horn a spectrum 
analyzer. An example of a MeasurementResuJt object In a dis- 
play application could be aTraceDisplayltem that laiows how 
to read a MarkerfViR and generate marker infonnation for the 
display. 

The nieasiu-ement result layer h;is no knowledge nf how^ or 
where its input data is generated. Its mput can come either 
fi-om other MeasurementRestjfts or from the fundamental infor- 
mation layer his thus free of any hardware dependencies. 
This layer uses ttie fLmdaniental information layer to coordi- 
nate the hardware activity. 

Fundamental Infonnation Layer. This layer performs the spe- 
cific activities that orchestrate ti\e hardware components 
to achieve a desired result. Tlie objects in the fundamental 
information layer know about specific hardwiire capabilities. 
They keep the hardware objects isolated from each other 
and also generate selfHlescribing, haid ware-in dependent 
data The fmidamental information layer applies hardw^are 
corrections (e.g., compensations for haixlware nonlineaiiries) 
to the measured results. 

The fundamental information layer contains three major 
components: a state machine with sequencing information 
that controls the objects in the layer, a production object 
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that is responsible for orchestraiing the hardware compo- 
nents, and a result object thai is responsible for postpro- 
ce^ing data. Examples of fiindamental information layer 
objects include SweepFJ* which Is responsible for me^^uing 
frequeno^ ^)ectra in a spectrum analyzer application* and 
the display list inteipreter in the display application, which 
is re^onsible for connoUing the instrument display. 

Instruineiit Network 

The tnstnimeni network contains the objects thai facilitate 
interapplication communication* mcludingan Application - 
Arc h we object, which is responsible for naming and pro\1ding 
infomiation to applications, and an ApplicatiDnScheduler object 
that schedules the threads that niake up the applications. 

Hardware Layer 

The hardware layer contains the objects that control the 
instniment hardware. These objects contain ver>' little con- 
text information. There are iwn types of hardwjire objects: 
device objects, which dri% e a simple piece of hardware, and 
assembly objects, which aie collections of hardware objects. 
Hardware components are organized in a hierarchy much 
like the composite pattern foimd in design patterns.* Hard- 
ware objects are accessed through haiuiles like the proxy 
|.>attem described in the patterns book/^ Handles can havT 
either read permission or read-\^Tite permission. Read per- 
mission means that the client can retrieve tlata from ihe 
object biit is not al>le to change any of the parameters or 
issue commands. Head-write pennissic^n allows both. Per- 
missions are controlled through the hardware resource man- 
ager. 

Communication Mechanisms 

Two niaiti t (Jtnmuniiatjon mechanisiTis gltte iJie iirchiiecture 
together, agents and events. Agents translate the language of 
die user Cclient) into the language of the sender (appiicalion). 
Different kinds fjf agents apply different kinds of tj"anslaiions. 
For instance, a client may enter informatie>n in the form of a 
text string, while its taiget application niay expect a C-++ 
method invocation. Thus, the client would use aspeciahzed 
agent to translate t lie input information into messages for 
the taiget application (the* server). 

Events are mechanisms used to notify mibsrribfirs (objects 
thai want to be notified about a particular eveiit) about state 
changes. We decideti to use eveiits because we wanted to 
have t hi rti -party notification, meaning that we did not want 
ih*" pi/htishers (objects that cause an event) to have to know 
a hot 1 1 the suhscnbers. 

There arc two types of events: active and passive. Active 
events poll the subject, whereas passive events wait for the 
subject tf> inifiatc the action. Our event mechanisms ajul the 
concepts of subst-rihers and publishers are describtnl in more 
detail later in tliis paper. 

Use of Fusion 

In selecting an object-oriented m(^thr>d to gui(U^ our develop- 
ment, we were looking for a method that would be easy to 
learn and lightwfMjihl, and would not add too nuich overhead 
to our exi.sling dcv<4(>iun<*Jit j process* We were a newly 
formed team with experience in our problem domain tuirl in 



emhieclded software development, but little experience in 
object -ori en led desigi^. We wanted to minimize the time and 
resources invested in working with and learning the new 
technology until we were fairly certain that it would work 

for us. At the same time, we wanted to have a formal pnx^ess 
for designing our system, rather than approach the problem 
in an ad hoc manner. 

Fusion (Fig. 2) met these requirements. It is a second- 
generation object-oriented methodology thai Ls fairly light- 
weight and easy to use.^ 

For the most partt our use of Fusion was very straightfor- 
ward. We started with the system requirements, and then 
generated a draft of the system object model and the system 
operatioits of the interface model. We also generated data 
dictionary emries that defined our objects and tlieir inter- 
relationsltips. Tliese documents made up the analysis docu- 
ments. W'e did not develop tiie Ufe c*ycle model because we 
did not see how it contributed to our understanding of the 
system. As time went on, we discovered that we really did 
not need it. 

From the analysis model, we mapped the analysis onto a 
design and generated the object interaction graphs to show 
the interactions bet\^^een the objects. We then genemted the 
visibihty graphs and derived the class descriptions. These 
were straightfon^'ard processes. 

By no means did we go through this entire process iji one 
pass. For us, using Fusion was an iterative prot^ess. Our sys- 
tem was cieaily too large to analyze and design in one pass. 
If we had tried, we would have been ovenA heltned with the 
details, Ir^tead, we riuide a first pass to identity' the priniaiy 
objects. We then divided the system into subsystems and 
recursively applied the Fusion method to each subsystem 
level to discover the higher-order objects at that level. 

For instaiTce, at the topmost level we identifie<l the nia,jor 
components of the finnware framework: the t^lieiit inteiface 
layer, the measmemcnt result layei; and the fundamental 
infonnation layer (seM* Pig, -V). We tlien skHrhefl out the m- 
teractions between these ccjmponeiii.s, repealed the prOf*ess 
Uyr each of the subsystems, and explored the details within 
each of the c^omponents of the subsystems. 

We did not apply the iterative process simply lo find details. 
It was also a way to che<*k the lop-Uwel ^tialysis and tlesign 
and Feed back intfi the procc^ss auy thing that we bad o\'er- 
looked in the liigher-level passes. These checks beli>ed to 
make our system implementable. Through external project 
revieift^ vvith oi)ject-oriented experts, we also discovered 
other ways to look at our abstractions. For itistitnce, with 
our original analysis, our focus was on I he subsystem that 
performed th** measurement funciionalitiesof the instru- 
ments. Thus, we ended up with an architecture that was 
focused on nu^asurement. We had layers in the system that 
handlefi the different aspetis of obtaining a measurement, 
but few layers that supported the instnnuent finnware. It 
was not until later, with outside help, that we saw how the 
patterns and rules for decomposing the instrument function- 
ality into Layers applied equally well to sub.sy stems that were 

' DflfiiLin patterns arj? hasfid on the concept that there are certain repealed pioblenis in soft- 
ware engineannQ thai appear at tlie corrfjnnBni jnie(':jrtiDn fevet DeRtqn Dattsfrns are de- 
scribed m morB detafi later in lliis ^fttcfe 
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not measurenient related, such as the display or the file sys- 
tem. We were also able to abstran the difTerent funcdonali- 
ties into the concept of an application and use the san^e 
rules and patterns to deciiJe how the re.^Kinsjbilities within 
an application ought to be distributed. 

We found Piisif>n to be an eas>'-to-iise and useful methodol- 
ogy'. This nieihofi provided a clear Hepamtlon l>etween the 

anal^'sis and the design i>hases. so that we were alile to gen- 
erate system analyses tliat were not linked to implementation 
details. 

Of course^ no rnerhtHloIogy is perfect for e%-ei>^ situation. 
We made sonte ntinor modifications to the method along 
the way, as well as some extensions (see Fig. 2), which will 
be described later. For instance, we omitted the life cycle 
models. Since we knew that we were going to im|j lenient 
our system in C++, we used C++ syntax to label our mes- 
sages in the object graphs and C++ class declarations when 
we generated the C++ cJasses. We also did not use the state 
diagram portions of Fusioti to generate states for our state 
n^achines* We felt that we did not need tliis state machine 
facility and thus freed the staff from having to leam yet 
another notation. 

Extensions to Fusion — Analysis Phase 

In cjur desire to perfomt object analysis more consistently, 
our team developed extensions to Fusion thai helped non- 
obj eel -oriented practitioners make the paradigm shirt to the 
object-on en te<l niind-set tnueh more easily 

Many developers and managers naiveiy assume that a one- 
week c^lass on ot^jtKl -oriented Icchnology is suffuMent to 
laimch a team itito develoiKing obje<'t -orient erl software. 
While this nmy )>e a necessiuy condition, it is not suincien! 
for file siK'ccfisftil aequisititin and aptJlicaiion of r>l>jcct,-ori' 
ejited iecluK>log>'. 

Many texts and courses on object-oriented methods treat 
the analysis phase as merely the identification of nouns that 
are objects ^md their relationships with one another Having 
conveyed this, the analysis sections of these books then 
focus on method notation rather than helping the notice 
overcome the biggest obstacle in objcct-oilentecl analysis^ 
the identification of objects. 

Without sufficient help, novices produce analysis diagrams 
tiiat conform to the object notation, but merely recast ideas 
frotn either ihe structured analysis ])aradigm or from some 
home-grown j)ai:adignr The circles of stnictured atmlysis 
and design are tmiied into boxes atul, voila. an ohjecl dia- 
gram is boni. 

Our team w^uj not spared this experience, Ftnlimately, we 
consulted object-oriented experts who taught us what to do. 



Thus* we developed an analysis technique that could be con- 
sistently applied project -wide to help the develo|>ers transi- 
tion frotn structured to object-orient etl aiialysls. This was 
critical to our facilitating software reuse, the primary goal of 
the project. 

Object Identification 

Successful objt^n -oriented analysis begins with identifying a 
model diat captures the essence of the system tjeing created. 
This model is made up of beha%iors and attributes that are 

abslf^iiions of what is containeti in tlte system to accom- 
plish its task. 

What makes a gtKJd abstractiDn? The answer to this qvi^^tlon 
is critical to the effective use of object-oriented technology; 
Unfortunately, identifjing the wTong aljstracrion encourages 
a pro(*ess known as "garbage in, garbage out." Fiirihemiore, 
the right abstraction is critical to tjie ease with which a 
developer can implement the object model. It is possible 
to generate a proper object model that camiot be imple- 
mented. The key is in the choice of the abstraction. 

What makes an abstraction reusable? The answer to this 
question is critical to achie\ing the value-added feature of 
object-oriented technology that is needed to achieve soft- 
ware reuse, t Understanding the context in which reuse can 
occur is important. 

All analysis Dame work exists that i"an be used to guide the 
identification of abstractions. Tliis framework has the added 
benefit of guaranteeing tlial the resultant object model de- 
rived from its tise is realizable. Furtiiemiore, its fotmdalion 
is base^l on the premise tJiat softwai*e reuse is the ultimate 
goal. 

hi developing our analysis, we noted the questions the 
exi)eris woultl ask when presented with our work. Funda- 
mentally their questions foctised on uitderslanding the 
re.sponsihiliiies of ti\e abstractions that we had identified* 
Resptjnsibility, it turns out, gives rise lo the siate and behav- 
ior of an ohject. F^revious researcli on tliis topic* yielded ;m 
article'* thai discusses responsibilily-t*Lused tlesign, imd 
describes an object-oriented design method that takes a 
responsibility-driven approach. We synthesized this knowl- 
edge into what can be described as tvspofisibili(j/-i?a.Hed 
anah/sw. 

This new analysis technique is based on a pattern of three 
interacting at>stractions: the dieuf, the policy, anti the mcrfi' 
(Iff Ism. Fig. 4 ilhisr rates the object itiodel for the client-policy- 
mechanism framework. 

Tlie chent abstraction reqtiests services, initiates actwities 
that change the system stiite, and queries for refiuest-speciric 
status within the system- 
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The policy abstraction decides when and how a request will 
be acted upon. It accepts the client request and, based on 
the resporisibility given to it by the analyst, chooses the ap- 
propriate way in which the work will be done. In performing 
this responsibility it sets the context for the relationships 
between the system components. 

The mechanism abstraction actually performs the change to 
the system state. If the operation is a state qttery, it returns 
the desired information. It does not return context informa- 
tion related to the operation being discussed. Ttie meclianism 
abstraction makes no decision as to w^heilwr it is appropriate 
for it to perform an operation. It just does it. 

As an example, consider creating a software application to 
read tlie nurent market value of HP stock. The client-policy- 
me(^hanism analysis of tlie problem, at a very higli level, 
yields at the minimum three abstractions: an abstraction 
representing the u.ser (the client), iin abstraction that repre- 
sents when and how the HP stock infonnation is to be 
acquired (the policy), i^ici lastly, an abstraction tiiat know^s 
about the value of HP slock (the mechanism). Tlie mecha- 
nism abstraction, when implemented, becomes the softw^ai'e 
driver for acquiring the stock price. In one instance, the 
mechanism olyect reads the %'alue of HP stock from a server 
on the Internet via telnet, hi another instance, the mecha- 
nism acquires the stock value via http. (Telnet, anrl http are 
two internet commimi cation protocols. ) The policy abstrac- 
tion determines how often to access the mechanism. Ir^ onr 
case it fietermined how often, that is, the time inteival used, 
to poll the mechanism. The chent object receives the restil- 
tant infonnation. 

From a software reuse perspective, mechanism abstractions 
are the most reusable components in a system. Mect^aiHSins 
tend to he drivers, that is, the components that do the work. 
Since the responsibility of a mechanism is context-free, tJie 
work that it does has a high probability of reuse in other 
contexts. Beuig context-free means that it does not know 
about the conditions required for it to perform its task. It 
simply acts on the message to pertbmi its task. In the exam- 
ple above, the mechanism for acquiring tlie stock price can 
be used in any application rcquiriiig knowledge of the HP 
.stock price. 

Though not as obvious, using the client-policy-mechanism 
framework gives rise to policy al>stra€( ions that are reusable- 
In the extunpk^ above, tJie pohcy abstraction idenl.iried can 
be reused by other applications tiiat require that a Jiiecha- 
nism be polled at specific time intcrv^als. Making tJiis hap- 
pen, however, is more difficult because the impleni enter 
must craft the policy abst Tactions with reuse in niuid, 

Tlie analysis (echnique described above attempts to identify 
client, policy, merhanism, and the contexts in which tiiey 
exliibit their assigned beliaviors. VViien pohcy roles are trivial, 
they are merged into tlie client role, producing the familiar 
cHent/serV'er model. This reduction is coimterintuitivc. since 
n^ost client/serv^er model implementations imbed policy in 
the serv^er. How^ever, from a solYware reuse point of view, 
it is impiortant to keep the serv^er a pure mechanism. On the 
other hand, it is also hnportant to resist the temptation to 
reduce the analysis to a client/server reiationship. Doing so 
reduces both the quaht^^ of the abstractions and the ojjportu- 
nity for reusing policy abstractions. 



These three abstractions together define the context of the 
problem space. Experience has showTi that to produce a 
clean architecture, it is important for each abstraction to 
have one responsibility per context. That is, a policy ab- 
straction should be responsible for only one pohcy, and a 
mechatiism abstraction should be responsible for doing only 
one thing. 

On the other hand, abstractions can play mtiltiple roles. In 
one context an abstraction may play the role of n^echanism 
and m another context be responsible for policy. An example 
Ulustiates this point more clearly. Consider the roles in a 
family unit. A young c hild perfonns requests made by a 
parent who in turn may have been asked by a granclparent 
for a specific activity. In a different context, for example, 
when the child growls up, it plays the role of parent for its 
children and its parents, who are now grandparents. In this 
latter setting, the parents are the policy makers, the grai'id- 
parents are the clients, and the childien (of the child now 
grown up) are the mechanisms (see Fig. 5). 

Just as, depending on context, a specific individual plays 
different roles, so it Is true with *i^>stractions. In one context 
an abstraction may be a mechanisiri and in another, a policy. 
Tlie critical nile to keep hi mind wlien using the elient-policy- 
mechanism framework is that tiiere should only be one re- 
sponsibihty per abstraction role. 

Hierarchical Decomposition 

Anotiier example of systems that illustrate the single-role- 
per-context nile is found in the hierarchy of the military 
forces, hi tiie Ignited States, the conuiiarifler in chief issues 
a command, the joint chiefs rest>onri to the commaiifl arid 
determine the methc^ds and the timing for executing f he 
conuuandi and the militaiTy' forces complete the task. In a 
different context, the joint chiefs may act as cheats to the 
admiral of tiie navy who determines the methods and timing 
for the subordinates who execute the task (see Fig. t3). 

In each of these examples there is a chent, a pohcy, and a 
mechanism- In one context, a person is responsible for 
policy decisions. In another, the same person is responsible 
for mechanism or chent activities. It is this concept that 
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gives rise to the use of the chent-policy-Tnecrhaiusni frame- 
work in helping to perform tnerarchical det^omposition of a 
problem domain. The repetitive identification of roles, con- 
texts, and responsibilities at ever finer levels of granularity 
helps identify the soluiion space for the problem doniaiiL 

The firmware framework team performed hierarchical 
decomposition by identifying roles, contexts, and responsi- 
bilities. These respoasibilities definetl abstractions that pro- 
duced objeet-s kmd groups of tJbjecis during the implenienta- 
don phase. In tiie early phases of our novice objetn -oriented 
project, tt was exjiedlenl to use tlie words object anti abstrac- 
tion interchangeably. As the team gained experieiu'e and 
became comfortable with object-oriented technology and its 
implementation, the distinction between the abstraction and 
its resulting objects became much better appreciated. 

Tlie analysis tecriinique based on tJie client-pohcy-mechamstn 
framework resulted in a hierarclncal decomposition that 
yielded layers and objects as shown in Fig. 7. Layers are 
groups of objects tliat interact mth one anotJier to peifomi 
a specific resi*onsibility. I^yens have no interiaces. Their 
main fimction is to hold together objects by responsibility 
during analysis to facilitate system generation. For example, 
many software systems include a user intjerface abstraction. 




-^ InstantJahle AlisifBCtlon 

— — — Nonidstaniiabie Abstfactton 

Fig. 7. ;\ii alhstractioii decomposition. 



However upon problem flecomposition, the user interface 
tibstraction typically decomposes into groups of objects dial 
collaborate and use one anotlier to satisfy the responsibilities 
of the user interface. Wl\en the abstracrion is implemented, 
it usually does not produce a siiij^e user interlace object 
with one unique interface. 

Much of this may not be discovered or decided until the de- 
sign phase H However, knowing about it in the analysis phase 
maximizes the identification of abstractions and the comple- 
tion of tiie analysis. 

Creation Model 

Many tinies discussions about abstractions resulted in intim- 
gibles tliat were difficult to grasp. To alieviate tliis probleni, 
tihe team supplemented Fusion with a dependency model 
showing object dependencit*s ^md iiuJicating when objects 
shtmld l)e created. Tilts provided devetojjers with a concrete 
picture of which objects needed to l>e available first. 

Consider again the HP stock price application. Let the mech- 
anLsm object be represented by ol)ject A and let the policy 
object be represented by object li Fig, 8 represents a crea- 
tion model for the objects under dtscussiorh It shows that 
object A has to be created before objtH^^t B. This means that 
the mechanism for acquiring the HP sttjck pric^e is created 
first. 'Oie objec I that <ielennines how often to acquire HP 
stock price caji only l)e created after ol>ject A. Tfiis example 
creation model is one of .several that were discussed during 
the analysis phase to clarify the roles of the abstractions. 
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Extensions to Fnaion — Design Phase 



Tliread Start 



We made extensions to the Fusion process with threads, 
design patterns, and reuse* 

Threads 

Our most extensive modi fir ations to Fusion in the design 
phase were in tlie area of tlu^eads. Our real-time instrument 
fumware systems, which Eu^e very complex^ must deal with 
asynchronous events that tnterrupt the syst4?m as weU as 
send control commands to the measurement hardware. 
For examplcj measurement data h<uu Itu^ analog-Lo-digitiiJ 
converter must be read within a certain time period before 
it disappears, and there may also be measurement hardware 
that needs to be adjusted based on these dynamic data 
readings. 

There are also many activities going on in the system that 
may or may not be related. For example, we may want to 
have a contirmous measurement nmning at the same time 
that we nm some small routine periodicaiiy to keep the mea- 
surement hardware craUbrated. Traditionally, a monolithic 
code consult cl performs all of diese tasks, liow^ever, since 
some of these actmties may only be peripherally related, it 
makes more sense to place these tasks in differeiu threads 
of execution. Each r.bread of execution can lie thought of as 
a path tlu'ough the code. These threads of execution may be 
either regular processes or hght weight processes, and they 
may or may not share resources. In this paper, the term 
thread is used to mean a thread of execution, not necessarily 
to denote the preference of a lightweight process over a 
regular* one. For ir^stanee, it wotild make sense to keep the 
task tiiat performs the measurements sepaiate from tlie task 
that checks the front panel for user input. 

Fusion provides us with information on how to divide the 
beha\ior of the systeni into object s» hut Fusiori does not 
address the needs of our real-time multitasking system. It 
does not address how the system of objects can be mapped 
into different tiireads of execution, nor does it address the 
issues of interprocess communication with messages or 
semaphores. Lastly, no notation ii^ F^ision cim be used to 
denote the threading issues in d\e design documents. 

Thread Factoring 

We extended Fusioji thread support iri twf:i ways. First, in 
the area of design we tried to detennijie how to break the 
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Fig. 9. Alt example of a time-thread map* 

system into different threads of execution or tasks. Second, 
m the area of notations we wanted to be able to be able to 
denote diese thread design decisions in the design docu- 
nrents. 

Our main emphasis was on keeping these extensions hght- 
weiglit. and easy to learn and keeping oLir modifications to 
the mminium needed to do the Job. We wanted a simple sys- 
tem that would be easy to lemTL, rattier than a powerful one 
that only a fei-v people could understand. 

We adopted portions of Buhr and Casselman's work on time- 
tlueaci maps to deal with thread design issues such as the 
identification and disco veiy of tlneads of control withui the 
system. *^'^^^ In our design, a time-thread map is essentially a 
collection of paths that are superimposed on a system object 
model (see Fig. 9). These pat I us represent a sequence of le- 
sponsibilities to be perfonned tluoughout the system. Tliese 
responsibilitT,' sequences are above the level of actual data 
or control flows, allowing us to focus on the responsibility 
flow without getting involved in the details of bow the exact 
contrcjl flow takes place. We then applied the process of 
fliread factoring, as described by Bulir and Casselman, 
where we brought om^ domaui knowiedge to bear on decom- 
posing a single responsibility path into multiple paths. These 
paths were then mapped into thieads of execution ftirough- 
out our systeuT. 




Fig. 10* An object interaction 
graph (01 G). Tlus representation 
is ail exteniiiaii of a Pusioi^ object 
iiirerat'tioji graph. The letters in 
ftrmt af the OIG numbers associate 
a thread of execution with a par- 
ticular me.ssage 
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Fig. 11, A thread map slio^^lixg an example of thread faeloring. 
fa) Before factoring, (b) .^er factoririfi. 

With the F'usion method, we had akeaciy identified the areas 
of responsihiJity. We tlien used tliis thread heuristic at iJte 
beginning of our design pliase in those places wfiere we liad 
already identified the objects in the system, but where we 
had not yet designed the interaction among the objects. We 
c!ealt with the conciirrency Issues at the same time that we 
(iealt witli the object interaction graplis shown ui Fig. 10. 
We also performed thread :fectoring and divided the system 
into multiple tltreads. 

The thread map m Fig. 1 1 depicts an example of tlu-ead fac- 
toring an application in our system. Usuig Ftision, we identi- 
fied a path of responsibility through the ol>jecls CI, MR. and 
FI (client inteiface, nu^asurement results, and fundamental 
infonnation). Inpitts enter the system through (.1, and Ihe 
respoiisibiUty for hantlling the input goes througli the various 
layers of abstraction of MR and FI. Sinc^e inforiniition from 
the measurement Itardware enters the system through FI, 
FI may have to wail for informatioti. The infonuaLion then 
flows goes back up fundamental information to MR and then 
possibly Ijo other applications, 

CUearly, tlte sj^stem worked fine as it was. However, we 
wanted to fmd where we could break the thread of exeeu- 
Mon mid perform thread factoring. Many issues, such as 



questions about performance, were raised at this points 
For example, if the thread is executing in part A of the ^^s- 
tem, it may not be available lo perform services m part B 
of the sy^em, TTius, in our sj'stem, we could ha^^e a thread 
pick up a user request to change the measurement hardware 
settings and then traverse the code in the hardware setup 
roatines to perfonn the hardware acjjustments. However, 
wliile it was doing so. the thread would not be available 
to resf><.>nd to user requests. This might impact the rate at 
which die system was able lo senice these requests. There- 
fore, we broke the user thread at the CI object botmdary and 
gave tiiat layer its own thread. 

Next, we tried to find a place where we could break the 
thread that goes through MU and FI. Clearly, the place to 
break was between ME and FL Making the break at this 
point gave us several flexibihties. Rrst, w^e would be able to 
w^ait at the FI thread for data iind not ha\'e to be concerned 
widi staning MR, Second, de^'elopmg components that were 
all active obJecUi allowed us lo mix and match components 
much more easily. 

Mapping a system onto threads Is a design'time acti\ity^. 
Thiiddng about the thread mappuig at this stage allowed us 
to consider concurrency and the beha\loral issues at the 
same time. 

Thread Priorities 

Aher we had identified the threads of execution, we needed 
to assign priorities to the tiireads. Note that this is mostly a 
uniprocessor issue^ since priorities only pro\ide hints to the 
operating system as to how to allocate CPU resources among 
threads. 

hi the finnwaiT framework project, w^e took a problem de^ 
composition approacli. We reditcetl the architectiire of our 
system to a pipeline of simple consimier/producer patterns 
(stM^ Fig. 12)^ At the data source we modeled the analog to- 
digital e< inverter (ADC) interrupts as a thread producer gen- 
erating data that entered the system with FI as consumer. 
FI, in turn, served its the produ^-er to MR, and so fortli. 
[npittii may ^dso enter the system at 1 he user input level via 
eitlier the fitjnt panel or a remote device, 

Wf* flecided to give the highest priority to those tlueads that 
intioduced data into the system from the physical environ- 
ment so tliat tliey could respon<l to events in the enviromtienl 
quickly. Tliose tlireads included the user input tltreads and 
tlie .ADC inteiTupt thread. 
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For thread priorities m the rest of the system, we considered 
three possibilities: that the producer priority was higher 
tiiaii that of the consumer, that the two priorities were 
eqiiai, or that the consmner priority was iiigher thaii the 
producer priority. We luled out setting tlie priorities to be 
equal because iJiat would be equivalent, to having no i>oUcy 
and would just let the systems run without any direction. 

Making the producer priority liigher than that of the con- 
sumer made slu~c that data was generated us quic kly as pos- 
sible- Lhifc^rtiinately, since we continuousiy acquired data in 
our system, (jur dala generation could go on forever imless 
we explicitly stopped Ute process atid handed control to the 
higher leveL 

AJtematively, if we ga%'e the consunier thread the liigher 
priori tyt it w<jukl have priority over the pi'oducers with 
regmtl to CPU tune. However, without tlie data generated 
front the producers^ the consumers would block and be un- 
able to nm. Thus, if the data eoiisunuiig chain had a higher 
priority Uian the data produeerSi the threads would run 
when data was available for them to process. This eluni- 
naled tlie necessity for the consumers to give up the CPU 
explicitly. 

Threads and Synchronization 

Another tluead issue we coJisidered was how to present the 
thread conmiunicatdon and synchrcinization operating system 
primitives to our system. We saw two alternatives. We could 
either exjjose the system level operatuig system calls to tiie 
sy stein or encapsulate the operating system primitives mside 
objects so that the rest of the objects hi tlie system could 
talk to these objects. For other system objects, it would be 
like conmiunicathig with nonoperating system objects. 

We chose the latter approach. We created operating system 
oi)jeci.s sucii as tasks and semaphores to encapsulate oper- 
ating system (unctkjrvahties. This approacii allowed us to 
model the operating system primitives as objects so that tiiey 
would fit in well with the FiLsion process and give us a clean 
mode] and good code reuse. This approach also had the side 
affect of isolating oiu' system from the operating system 
APL There WT^re drawbacks with this approach, but they 
were not major. Reference 7 contains more details about 
both of tJtese approaches. 

Thread Notation 

We itsed thiead notations within our Fusion diagrams ui two 
ways. First, we used the thread map notations to show 
sketches of thread flows (Fig, 11). These simple notations 
gave us a general iilea of the thi'eaci activities in the system. 
We adopted only a few of the notations that Buhr and 
Cassehnan use, employing the paths and waiting places that 
show tlie behavior of die system. We did not use their nota- 
tion to handle the (hfferent types of synclmjni/ations be- 
cause we did not feel that this vviis the lev^el of detail appro- 
priate for w^hat we needed. Tliis method gave us an oveniew 
of what the system looked like without bogging us down in 
the details of how communication and synchronization were 
implemented. 

For our second method of using thread notationSt we ex- 
tended the Fusion object interaction graph (OIG) notations 
to describe tlireads more fonnally (Fig. 10). We added letters 



in front of the OIG ntmibers to associate a tJiread of ejcecu- 
tion with a particular message. We also experimented with 
coloring the threads. 

Design Patterns 

Design patiems have become popular in the object-oriented 
world only recent ly Design patterns evolved from the real- 
ization that certain software engineering patterns ai*e re- 
peated. Tiiese patterns are not at the implementation level, 
but at the level of component interactions, nte idea here is 
to look at software design problems at a liigher level so that 
recmimg patterns can be identified and a common solution 
applied. 

For instance, there is often a neeti m software systems for 
one or more objects to be notified if the state changes in 
another object. For example, if the value in a database 
changes, the spreadsheet and the word processor currently 
displaying that value need to change their diuSpJays, The 
observer pat lem, described in the design patterns book;^ 
shows how to set up the relationship among these objects. 
It describes when a pattern may be appro]:)riate for solving 
the notification problem and some implementation bintij and 
potential pitfalls. 

Design i>atterns catne to our attention a year or so into the 
projed . By tbeti, we had already completed most of tiie de- 
sign. Therefore, we tUd not use them as templates to build 
the system from scratch. Instead, we used the design pattern 
catalog to vahdate designs, hi looking tlirough our system, 
we found potential applications for over half the patterns in 
the design patterns book. We then compared our desigti with 
tiiose patterns. 

We fomid patteiTis to be useful for design vahdation, hi some 
places, they helped us impix)ve the design. For instance, the 
hardware components aie accessed tiirough haiilware iian- 
dles, which are very similai' to the protection jiroxies de- 
scribed in tlie patterns book. The hai'dwaie ajTliitectme 
itself is an example of a ccjmjjosite pattern. A composite 
pattern is an organization of object ~s in wliich die objects are 
aiTaiiged in a tree-hke liierarchy m wlucli a client can use 
the same mechanism to access either one object or a collec- 
tion of objects, Tlie descriptions of composite patterns in 
She design patterns book also helped us to identify and clarify 
some of f he issues related to building composites. 

In other areas in the system, we found om^ analysis to be 
more detailed because of our extensions to identify objects 
using the client-pohcy-mechimism framework. We have an 
event mechanism hi the system to hifonii some componenl 
when an action has occLured. This mechiuusm is very sirniiar 
to that of the obsen-er pattern mentioned earlier. The oh- 
sender pattern describes two components: a publisher aiid 
a subscriber, which define a methodology for handling events. 

Our event pattern is shghtly more sophisticated. We placed 
the event policies into a third object, so we have tiiree com- 
ponents in our event pattern: a subscriber, an actor (pub- 
Usher), and the event itselT Actors perform actions, and 
subscribers want to know when one or more actors have 
performed some action. The subscriber may want to be noti- 
fied only when all of tiie actois have completed their actions. 
Tlius, w^e encapsulated pohcies for eheiit notification uito 
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the event objects. An actor is only responsible for teUing 
events thai U has performed some actioa Events maintain 
the policy that determine when lo notify a subscnber. 

This arrangement gives more flexibility to the sir*stem be- 
eatise the design-patterns approach allows the poUcy for 
noCiilcadon to be embedded in the actor. In our case, we 
also have the freedom to customize the policy for different 

uistances of the same actor under different situations. 

We feel that the main ad\*antage of not using the patterns 
until the system design Is done is that the deveioijer will not 
fall into the trap of forcing a pattern that resembles the 
problem domain into the solution. Comparing our problem 
domain with those described in the patterns book helped us 
to understand more about our context and gave us a better 
understanding of our system. Also^ as many other object- 
oriented practitioners have reported, we also found patterns 
to be a good w^ay to talk about component intenu.'tion design. 
We were able to exchange design ideas within the team in a 
few words rather than having to explain the same details 
over and over again. 

Scenarios 

Part of OUT system requirements included developing sce- 
narios describing the beha\ior of the system. Scenarios 
describe Uie system output beha\1or given a certain input. 
These scenarios are similar to the use cases described in 
reference 1 and are part of die Fusion analysis phase. How- 
ever, for people not conversant in object-oriented methods, 
these scenarios often do not have much meaning because 
the descriptions are far above the implementation level 
Whenever we presented our atialysis and design models, our 
colleagues consistently asked for details on whal was hap- 
pening in the system at the design level .Mthtjugh Fusion 
documents proxided good overxiews of the system as well 
as excellent dynamic models for what happened in each 
subsystem, petiple sttJl wanted to see the dynamics of the 
entire system. 

Tr» ex'plain how oiu" system works, we developed scenarios 
during the design phase. These scenarios were a collection 
of object interaction graphs placed together to sliow how^ 
the system would work, not at an architectural level but at a 
design and implementation level. We used the feedback we 
received from presenting the scenarios to iterate the design. 

The Fusion model is event-driven, in tJtat an event enters the 
system and causes a number of interactions to occur. How- 
ever we had a real-time system m wMch events happen 
asynchronously. We needed scenarios that were richer than 
what the object interaction graph syntax could provide. 

For example, our instrument user interface allows the user 
to riiodify a selected parameter simply by turning a knob, 
called file RPO (rotaiy pulse generator). One attribute liy 
which our customers judge the Sf*eed of our iasimments is 
how quickly the system responds to Rf^G input. Ttie user 
expects to get real-lime visual feedback fnjm the graplucs 
display. The empirical data suggests that reaMime means at 
least 24 updates per second. As the layers were integrated, 
we looked at the scenario in which the user wanted to tune 
the instrument by changing a parameter (e.g., center fre- 
quency). Tltls scenario led lo <tuestions such as: How would 
the system's layers behave? What objects ware involved? 



What were the key interfaces being exercised? Were the 
mterfaces sufficient? Could the interfaces sustain the rate of 
change being requested? WTiat performance would each of 
the layers need to delix er to achieve a real-time response 
fi-om the users point of \iew^? The answer to ihi^e questions 
led to a refinement of both the design and the implementa- 
tion. 

These design-level scenan^ ^s provided a better idea of what 
wouid happen in the s>stf ui and presented a more d>Tiamic 
picture. Since the scenarios encompassed the entire system* 
they gave the readers a better vi^w of system behavior We 
found them tci be good teaching tools for people seeking to 
understand the sj^stem. 

We also found that instance diagrams of the system objects 
helped us to visualize the system behavior. A diagram of the 
instaivtiated objects in ti^e system provided a picture of the 
state information chat exists in the system at rim time. 

Reuse 

To build reuse into a system, the development metiiod has 
to support and make expUcit the opportunities for reuse. 
The imaJysis extensions described earlier serve to facilitate 
the discussion of reuse potential in die system. The design is 
dri\^en by the biases encoded into the analysis. 

At the end of the first analysis and design pass, an entity 
relationship diagram will exist and a rudimentary class hier- 
archy will be knowTi. The more mature the team in both 
object-oriented technology and the domain, die earher the 
class hierarchy will be itlentitled in the development method. 
Additionid itiformation can be gathered about the level of 
reuse in the class hierarcliy during die analysis antl design 
phase. These levels of reuse are: 
■ Interface reuse 
Partial implementation reuse 
Complete implementation reuse. 

The ability to note the level of reuse in the work products of 
the development mctliod is valuable to die us*^rs of the object 
model. A technique developed in this project was to color 
code the object model. Fig, 13 shows two of these classes. 

Fixcept for defect fixes^ complete implementation classes 
cannot be mod died once they are implemented. This type of 
color coding aids developers to know^ whic^h components of 
tite system cati be directiy reused just by looking at the 
object model. 

Process Defiiution 

TJie pursuit of obj eel -oriented technology by a team necessi- 
talcs the adoption of fonnal processes to esrablish a mini- 
mum standard for development work. This is especially true 
if die team is new to object-oriented technology. Various 
members of the teimT will develoi> their undei-stxmding of the 
technology at different rates. The adoptif)n f>f stajidjwds 
enables continuous impn)vements to the process whUe 
shoriening the leani time ff>r the whole team, 

In tjie firmware framework project, we adopted processes 
to address issues like communication, quality, <uid schedule. 
We customizt^tl processes hke inspections and evoiutiunaiy 
dehvery to meet our needs. It is important to keep in tnbid 
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that processes desciibecl iti the literature a.s good practices 
need to be evaliiaied and customized to 111 U\e goals of a 
parti riiiai' teatn. The rt^tiini on in\^estmeiit ha.s to be ob\1oiis 
and the stanup time short fot^ the process to have atiy posi- 
tive impact on the project. 

Codhig standaitls, for example, can help the ream team a tiew 
language quickly, Tli€\v cmi tilso be used to filter out progranv 
mhig practices that put the source code at risk during the 
niaiiitenanc^e phase of tlie project, lliey also facilitate the 
esial)iisbrueiii of vvhaf to expeci when readmg source co<ie. 

Evalutionarj' Delivery 

We partnered with HP's Software hiitiative program to de- 
velop) what is aow kiiowTi as EVO Ftision/^^^^^ EVO is a man- 
agement process that cousuiicts a prodtiet ii^ small incre- 
ments. After each iticrement is completed, ihe de\elopinent 
process is examined for ijnprovements that might contribute 
towards the successful completion of the next increment. 

Each increment can have an antilysis, desigUt code, and test 
phase The product evolves over time into the desired prod- 
uct throtij;h repeated execuiion of small development cycles 
that atld greater mkI greater functionality. This process 
Iteips to focus the team and increases the probability that 
schedules will be met. 



IniSpections 

Much has been written about the value of inspections to 
softwaiT deveioptnenL Tliough much of the literattne 
fociLses on prodtiet qtiality, the inspection process also iden- 
tifies (that is, makes explicit ) other issuers. Once identified^ 
these issues can be quantitied into high, medimn. and low 
lisk factors. Their impact on tlie success of the project can 
be asceiiaiued and I be apprcjpriate action can be taken to 
manage their resohition in a tmiely matmen Institution of an 
inspection pi'ocess thus prraides the project nianager atid 
the project team with mi atkiitional means by which to 
gather mformation peitment to project completion. 

In a project, the use of a development method like EVO 
FtLsion, coupled with ;ni Itispectioti process* facilitates tJie 
discussioti of issues that relate to recitiirements. software 
aichitecture, sofrwaie integration, and code development. 
The benefits to the team me significant i>ecause these pro- 
cesses enable members to understand the product and its 
huictionaiiiy long before ihe debug phase beghis- 

Legacy Systems 

In inan,\ cases, it is not possible to generate a s>^stem com- 
pletely from scratch withi>ut tising legacy ct)dc. Tlic tlnn- 
ware framework project was no exception. 
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We found that the most straightforward approach is to en- 
capsulate the legacy code inside objects. This works for 
systenis that provide senlces to client objects. It also works 
for legacy' subsj^tenis that act as clients* such as language 
parsers. These parser components are not good framework 
citizens bec^aiise they alreadj^ have their own definition of 
the sener interface they expect, which may not coincide 
with the object -oriented design. 

We feel thai the proper approach is to perfomi the object- 
oriented analj^is and design without regard for the legacy 
system first, and then encapsulate the legacy code inside the 
proper objects. There is a strong temptation to design the 
object-orieni.e<l system aroimd tlie existing legacy code, but 
in our experience the legacy sj^stem may not have been de- 
signed witJi the appropriate object-oriented principles, Tlius, 
allowing it to afiect the analysis may lead to a faulty design. 

Summar>' 

Fusion is the resuh of the evolution of a long hnc of soft- 
wiire developrneru processes, like its predecessors, Fusion 
has its benefits, problems, and areas for improvement 

Benefits. Tiie benefits we derived using Fusion include: 
Lightweiglit and easy to use. We found Fusion to be easy to 
leani. There is lot of guidance in the process that leads the 
user from step to step. It is not mechanical, but the user will 
not be w^ondering how to get from one step to the next. 

• Enforces a common vocabular>\ Often in architect in g 
systems, the different domain experts on the tetim will have 
their owti definitions of what certain terms ttiearu Generating 
data dictionary entries at the analysis phase forces everyone 
to state their definidons and ensiues that inisundei-standings 
are cleared up before design and impleu^entation. 

• Good documentation tool. We found that the documents 
generated from the I-Xision process served as excellent docu- 
mentation tools. It is ail too easy, without the rigor of a pro- 
cess, to jmnp rigid in and start roding mul do the documen- 
tation later. Wlvs olleu happens is that schedule juessure 
does tiot dlow the engineer to go back and document the 
design after the coth ng is done. 

• Hides complexity. Fusion allow^s a project to denote areas 
of responsibility clearly This featiu-c^ ciuililes the team to 
talk about the bigger picture without being hcjgged down in 
tlie details. 

• Good separation between analysis and design. Fusion en- 
forces a separation between analysis and design and helps 
in differentiating between aichitectiual and implementation 
decisix^ns. 

• Visibility graphs very useful The xlsibdity graphs are very 
useful in thinking about the lifetime of the serv^er objects. 
Simt>iy exanuning the cotie all too often gives one a static 
picture and one does not think about the djnamic nature 
of the objects. 

Problems. Tlie ijroblems we encoimtered with the Fusion 
lui^iiod included: 

• Thread sui)t>oit. Although the Fusion method models the 
system with a series of con< current subsystems, this ap- 
proach does not always work. The threads section of this 
article describes our problems with thread suppon. 

• Complex details not handled well. Tliis is a corolhiry to 
Fusion's abihty to hide detmis. Do not expect Fusion to l>e 
able to handle every iBst detail in the system. In instnuuent 



controL there are a lot of complex data generation algon 
rithms and interactions. Although in theory it is possible to 
decompose die system into smaller subsystems to capture 
the design, in practice there is a point of diminishing re- 
turns, U is not often feasible to capture all rhe details of the 
design. 

Areas lor ImprDvement. The following are some of the areas in 

which the Fusion metJiod could he inipro%'€Hl: 

• Concurrency support. We would tike to see a process inte- 
grated witii the current Fusion method to himdle asjTichro- 
nous interactions, multitasking systems, aitd distributed 
systems. 

♦ CASE support. We went througlt the Fusion process and 
generated our dociunentation on a variety of word process- 
ing and draifting tools. It would have been very helpful to 
work with a mature CASE tool that miderstands Fusion. 
Some of the fiuiciioiialities needed in such a tool include: 
guidance for new Fusion usei^s, automatic generatioti of 
design documents, and automatic checking for inconsisten- 
cies in different parts of the system. Ttu-oughout the course 
of otjr project w^e evaluated several Ftision C'ASE tools, but 
none were mature enougli to meet our needs, 
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An Approach to Architecting 
Enterprise Solutions 



A frequently mentioned ailment in healthcare information management 
is the lack of compatibility among information systems. To address this 
problem, HPs Medical Products Group has created a high-level model that 
defines the major architectural elements required for a complete 
healthcare enterprise information system. 

by Robert A, Seliger 



HFs Medical Products Group (MPG) produces medical 
devices such as patient monitors aiid ultrasound in^aguig 
systems, whicli obtain physiological data froni patients, m\d 
clinical information systems, which docunienij rt*trieve, and 
analyze patient data. 

In Decenaber 1994^ MPG directed its architects to define ^md 
drive the hnplementation of im open, stiindards-b^ised MPG 
application system architecture that would enable: 

' Improved application development productivity 

' Faster times to market 

' Seamless integiation of applications developed by MPG 
and its partners 

• Integration with contemporary and legacy systems in an 
open standards-based environment 

To meet these objeriives and to help establish MPG as a 
leader in healthcare ijiforuiation systems, the Concert archi- 
tecture was conceived. Concert, is a software platform for 
component-based, enterprise-capable healthcare informa- 
tion systems. 

Tlie piiniary objective of Concert is to enable the decomposi- 
tion of healtiicare applications and systems of applications 
into sets of interconnec table collaborative comi>onents. 
Each component imj^lements importajit aspects of a com- 
plete healthcare application or system of applications. The 
components work together to realize fuUy functional appU- 
cations and systems of apphcations, 

A component' based approacli was pursued to leverage the 
fundamental precepts of good softwaie enguieering: decom- 
position, abstraction, and nioduhrity. We reasoned that an 
architecture that facititated decomposing large complex sys- 
tjems into modular components and at^stracted the details of 
their implementation would contribute to development pro- 
ductivity The ability to use these components in a variety of 
applications would expedite time to market, 

Ciu'cfiilly specified component interfaces would enable flex- 
ible integration of components in a seamless manner Openly 
publishing these interfaces would enable components devel- 
oped by MPG's partners to interoperatc with MPG*s compo- 
nents. The judicious use of healthcare and computing stan- 
dards would enable integration with systems based upon 
otiier arcliitectures. 



Conceit was developed by MPG in corxjunction with HP 
Laboratories and the Mayo CUnic, a strategic MPG partner 
It senses as the technical cornerstone for MPG's group-wide 
initiative to provide better enterj3rise solutions for its cus- 
tomers. Key aspects of the architecture havc^ also been ap- 
plied by HP Laljoratories and the Mayo Clinic to develop a 
prototype electronic medical record system. 

Concert also serves as the foundation for the technical de- 
velopment effort, of the Andover Working Group for Open 
Healthcare Interoperability. This MPG-led healthcare indus- 
try initiative was been formed to achieve enteriirise^wide 
multivendor uTieroperability (see page 89). 

Concert currentiy consists of the following elements: 

• A general reference model that organizes the architecture of 
healthcar'e enterprise information systems into a key set of 
arc h i tec tu rat i ngred i en ts 

• A model for software components tJiat can be implemented 
using CORBA-based' or Microsoft '^' OLE-based- technologies 

• An initial set of Concert components including their inter- 
faces and the policies that govern the patterns of interaction 
between the components 

• An approach for orgtuiizin^ Concert component Interfaces 
to represent component apphcation development, system 
Integration, £und systeni m^magement capabilities 

• An initial infonnation model thai provides an obj eel-oriented 
description of healtiicare terms. conceptSt entities, and rela- 
tionships to establish a common chnical basis for Concert 
components and the applications developed from them. 

Concert Components 

To facihtate the description of the Concert component 
model, an example of one of the components that MPG has 
developed will be used. The component, called iin mtter- 
prise commiinicator, is at the heari of the enterprise coni- 
mmiication framework (ECF) that MPG is developing in 
conjunction with cjther healthcare vendors and providers 
that form the Andover Working Group. 

An enterprise communicator is a software component that 
facilitates healthcare standards-based data interchange 
between healthcare systems and applications wit tun a 
healthcare enterprise. Different types of communicators 
encapsulate different healtiicare standards. The particular 
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Fig. 1. A healLhcrare srv^tem based 
on enterprise communiciitors and 
the Hi? data interchange standard. 



coirmiunicator that MPG Is curreniJy developing encapsti- 
Mes the Health Level 7 fHLT) 2,2 data interchange standard.^ 
Bg, 1 shows a system based on enteiprise conmiunicators. 

HL7 Is a widely used healthcare electronic data interchange 
standard. It5 priniaiy contribution is the specification of a 
set of messages that healthcare systems can exchange to 
share chnicaily relevant data. Examples include messages 
that enable apphcations to obtain the results of laboratory 
tests from the applications that have access to this data. 

The HL7 standard is not intended to be particularly prescrip- 
tive in terms of messaging technology or how o^essaging 
services shoulcJ be implemented. This has led to a variety of 
custom HL7 impfementations based on a range of teclmolo- 
gies. A typical implementation employs specially formatted 
character-encoded messages and point-to-point network or 
serial-line connections. An example of a character-encoded 
HL7 message is shown in Fig. 2. 

In t he Concert-based model, applications employ enterprise 
commtmicators to broker their HL7 data interchange needs. 
Enteiprise communicators provide applications with the 



necessaiy messaging capabilities, such as guaranteed mes- 
sage delivery and multicasting (i.e.^ sending several messages 
at once), Enteri^rise commtinicators also present HL7 mes- 
sages as object-oriented abstractions using both CORBA and 
OLE automation teduiologies. This eliminates the need for 
apphcations to parse the messages to extract tlie encoded 
data^ 

In addition, for legacy integration, communicators support 
TCP/IP interfaces through which apphcations that are not 
object-oriented can send and receive character^ncoded HL7 
messages. 

Why Components? 

The concept of componeni-hased systems has become 
increasingly popular over the last several years. There are 
currently many definitions of components and a variely of 
tools and technoiogies hav^e emerged to facihlate developing 
component-based systems, Many of the general concepts 
about what a (xmiponent is are similar across all of these 
derm it ions. However, there appears to be little agreement 
on tlie granularity of a component. Granularity depends on 
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Components and Objects 

Dbjects enaNe concepts \o be developed using abstractions that repre- 
sent real-world and computing concepts. The objects are interconnecied 
to form programs that perform useful tasks. Components ere also objects. 
However, components have the added dimension that they represent an 
economically and technologicaily practical way to organt^e and package 
an object-Driented system, A component system can be developed, mar- 
keted, licensed, maintained, and enhanced on a component basis. 

In an informal sense, components are just 'bigger^' objects. With this 
bigness comes the need, and fortunately, the technical feasibility to 
support computing capabilities that are impractical for traditional "smalT' 
objects. For example, most component development technologies enable 
a component's external interfaces to be accessed through several differ- 
ent programming languages, and these accesses can often be performed 
across a network. It would be overwhelming to support these capabilities 
for every small object, However, supporting the capabilities becomes 
practical when objects are organized into bigger components. 

Components can also be more cost-effective to develop and maintain 
than small objects, This is because components do more. Similarly, com- 
ponents can be more efficient to develop and maintain than traditional 
monolithic programs. This is because components don't try to do every- 
thing. 

In a well -architected system, each component wiff provide enough func- 
tionality to warrant development as a standalone entity that can never- 
theless be combined with other components to form fully functional 
applications, in a we 11 -architected system, each component will be a 
candidate for being catalogued as a product and marketed as an essen- 
tial building block for an overall system. 

Examples of healthcare-related software components include a compo- 
nent that describes and correlates medical terms based upon standard 
schemes for encoding medical terminology, a component that checks 
whether medications being ordered for a patient might interact in an 
adverse manner, a component that enables viewing physiological wave- 
forms in a manner that preserves aspect ratios and display size even 
when viewed on different display devices, and a component that enables 
applications to send and receive patient data based upon healthcare 
electronic data interchange standards. 



how much ftmctionaJity a component represents and how 
much code atid eoniplexity are embodied witliin a compo- 
nent implementation. 

In Concert, components tend to be medium-to-^large-grained 
objects, * For example, a Coneert component might be imple- 
mented by what is traditionally tliought of as mi executable 
prograrti, i^ is the case for an enterprise conimimictitor. 
Alternatively, a group of Concert components might be 
packaged wltliin a iibran^ However, a Concert component 
is rai'ely as small as a single C-i-+ or Smalltalk object. 

In generalj a Concert component is a portion of an applica- 
tion system that: 

• Implements a substantial portion of tJie overall application 
system's capabilities 

• Represents its capabilities via one or more modutlarly 
defined binary' inteifaces 

• Can be developed independently of other components 
« Is capable of efficiently communicating with other 

components over a network 



• Is the fundamental unit of configurai>i!ily, extensibility, 
replaceabllity, and distribution 

• Is t.lie basis for an open system througii the publication of 
its interfaces. 

In other words, a Concert component represents a signifi- 
cam portion of an overall application system, but is small 
enough to enable efficient and flexible composition with 
other components to form full-fledged applications and 
application systems. 

A key motivation for a component-based architertin-e is that 
it makes accomplishing the following architectural objec- 
tives nujcb ejtsier. 

• Simplification, Components can make tite approach to 
decomposing a complex application system into .smaller 
simpler pieces tangible tuid precise. 

• ReplaceabiUty- Existing components caji be readily replaced 
with new implententatioi^s as long as tJie new component 
supports the same interfaces as the component it replaces, 

• Configurability. Components provide a modular, precise, 
and mtmageabie basis for c"onfigunng a system, 

• Extensibihty^. New components with new capabilities can 
be added to an existing system in a modulai- and organized 
manner. The risk of breaking existing rapahilities that are 
well-encapsulated in existing components is minimized. In 
addition, new capabilities that are added to existuig compo- 
nents can be represented by new component mterfaces that 
represent the new capabUities without requiring changes to 
exlstijig interfaces, 

• Lidependence. The interfaces between components < lei me 
the **con tract'' between components that can enable iiide- 
pendent development as long as the contracts are respected. 

• Scalabihty, Components can be physically distributed or 
alternatively coUocated depending upon the computing 
infrastnicture available cmd desired price/performance 
profile. The componetit itUerfaces define what components 
connminicate about, and this conmiunication can be realized 
using same-maclune or network-based mechanisms. 

• StabUity. A variety of tools, teclmologies, and design mcthotis 
can be employed to implement the components, thereby 
enabling evolution of the implementation teclu\ology, tools, 
and methods \\1thou(; \ioiation of the architecttire. 

• Business-Centeredness, The efficient and timely realisation 
of the architectttral objectives listed above is the basis for a 
sigi\ificant competitive advantage. 

To achieve these objectives. Concert specifications primar- 
ily emphasize how apphcation systems are assembled from 
components. This approach pro\ides a great deal of latitude 
for application developers to define what capabilities their 
application systems will actually pro\ide. Perltaps most im- 
portant, the ajchitectiure also enables product teams to put 
more focus on developing the content of their applications 
because they can leverage a standard at^proach to 
constructing their application systems. 

Component Interfaces 

Concert components implemeiit object-oriented interfaces. 
An object-oriented mterface is a named grotcping of semanti- 
cally related operations that can be performed on a compo- 
nent. A component that implements a paiticular inteiface 
implicitly supports the functionality contract imphed by the 
interface. 
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The Andover Working Group 

To esiablisl^ a ccimmon implementation of data interchange stamiards m 
healthcare, in 1 996 HPs Medical Products Group led the formation of the 
Andover Woricmg Group (AWGI for open healtticare intefoperabilitv This 
program is sn industfY-wide effort to accelerate piog-and-ptav mteroper- 
abtiity between healthcare compuimg systems The lack of compatibility 
among mfomiation systems is one of the most frequently cited informa- 
tion technolcjgy problems facing the healthcare industry today 

In 1996, the core membership of AWG irKtuded fifteert healthcare ven- 
dors and three healthcare providers Each of these organizations conirib- 
uted engineering resources to work on definirig the enterprise communi' 
cation framework (ECF) for HL7 In addition, in t996> the AWG supporting 
membership included over one hundred additional vendors and providers 
These organizations attended early review meetings of the ECF and pro- 
vided the AWG wrth feedback and guidance about its processes, technol- 
ogy, and future directions 

The objective of the AWG is not to define new standards for interoper- 
ability. Instead, the AWG seeks to increase the commonality among the 
implementations of relevant healthcare computing standards. Standards 
such as HL7 walk a fine line between being prescriptive enough to be 
useful and being flexible enough to be widely accepted in the industry, 
However, inherent in this flexibility is the opportunity for implementers of 
the standard to make different implementation decisions Different and 
often incompatible implementation decisions reduce the likelihood that 
systems will inte rope rate. 

To overcome these problems, the AWG has developed an implementation 
of HL7. This implementation consists of detailed message profiles in 
which the specific HL7 messages that ECF-based applications can send 
and receive are described. The software that enables applications to use 
these messages easily is also provided in the implementation The core 
of this implementation is a software component eafled an enwrpriSB 
cammunicatof 

The derivation of ECF message profiles involved the iterative refinement 
of an elaborate object-oriented information model by the AWG represen- 
tatives. The enterprise communication framework software folfows the 
component architecture described in this article The result is a hjgh 
degree of interoperabdity in the form of data interchange between 
healthcare systems without the usual system integration costs 

The first example of ECF-basad interoperability was damDnstrated in 
October 1996 when twelve applications developed by six different ven- 
dors, running on three different computing platforms, were modified to 
use the ECF software. The applications were able to participate in a 
detailed scenario that simulated a patient's admission to a hospital, 
ordering of a series of laboratory tests and reporting of the correspond- 
ing results, and an eventual discharge from the hospital This level of 
interoperation was the first concrete proof of the effectiveness of the 
AWG as an organization and of the ECF as truly enabling software. 



For example, among th? interfaces that an enterprise com- 
municalor implements is the Application Connect interface. This 
inteiftice enables an application to connect to and discoruiect 
from a comnmnicator. ( )nJy coimecie(i aiipli<^aiions Ccm send 
and receive HL7 messages. 

Comj)onents l.hal implenieni similar <*a|jaljilities represenl 
these capabilities via the same iiiterface, F'or example, any 
Concert component that requires its client appUcations to 



explicitly connect and discomiect might implement the 
Ap pi E cation Connect interface. The effect of connecting and dis- 
connecting would dei>end upon the type of component, but 
ihe policies governing when and how to use the interface 

would be the same. 

Each objeci oriented interface enables a subset of a compo- 
nent's overall capabilities to be accessed and applied. A 

component ^i full net of object -oriemed inierfaces enables a 
component's full array of capabilities to be accessed and 
applied. For example, aJiorJier interface that is implemented 
by an enterprise conunmiicaior is Mt ssageManagBr. Tins inter- 
face enables a connected application eitlier to create a new 
message that can be populated with data and sent or to 
ol)tain a message that the conummicator has received from 
anotJier application. 

Many of the details of the Concert nK>del for software com- 
ponents come from the OMG's (;)bject Management Archi- 
tecture (OMA). The most notable OMA ingredient is tlie use 
of the OMG Interface Definition I.angiiage (OMG IDL) for 
specifying a Concert components obiecl-oriented interfaces 
independent of the technology used to implement the com- 
ponent and its interfaces. 

OMG IDL serves as the softwjy^e equivalent of the schematic 
sjittbols that electrical engitreers use to diagram circuits. 
For example, the symbol for an AMD gate clearly con\Tys its 
role witJiout relying on descriptions of the imderlytng cir- 
cuitry or fabrication technology (e.g., CMOS, TTL, etc). 

OMG IDL provides a standard and fonuaJ way to describe 
software component interfaces. Further when apphed 
wit hin the context of an overall component-based architec- 
ture, formjdly siJecilled interfaces can be used to create a 
level of precision tlmf helps ensure that important iurchitec- 
tural features and principles are reflected in products that 
are eventually developed. For examjjle. components that 
con^stitute a pjulicular i>rfHliJct can be examined to see if 
they c^orrec^tJy imj^lcmcrU the necessaiy interfac^es. The rolt^ 
that interfaces play m atlding precision to a software juchi- 
teclure is illustrated in Fig. 3. 

Antither advantage of defining inlejfaces Is that they can 
provide a shottluiJid ff>r describing comi>t)nents. The (Con- 
cert siJecificatiori curr*'Ully consists of less than forty inter- 
faces. JiiSt 1 he name of 1 he inr etfaces that a component im- 
plements is often ail ijne needs to untlersiand how to use the 
component. 

For example, the enterprise communicator interface Imple- 
mentationlnformation atlows access to implementation informa- 
tion about a communicator, including its product inmiher. 
softw are revision, and when it was installed on its current 
host. The interface Hostlnformation provides access to informa- 
tion about the computer that is hoslmg an enterprise com- 
municator, uicluding the hosts network name and the type 
of cjpei-ating system it supports. 

A simplified OMG IDL specification for an enterprise com- 
nutnicator H ApplicationConnect iiiterface is shown in Fig. 4. 
Tliis spetiilcation conveys the foilovvii;g information about 
the inteiface: 

TIic name of the interface is ApplicationConnect, 
The interface supports two (Operations: connect anci discon- 
nect. An appUcatton that wants to connect to an enterprise 
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Fig. 3. All illustration of the role that interfaces play in adding 
precision lo a software architecture, 

communicator p erf onus tlie connect operation on the com- 
municator's ApplJcationConnect interface. An application that 
wants to discoiuiect performs the disconnect operation, In 
either case, the application identifies itself by setting an 
appropriate value for the input parameter which_appltcation. 
i Under nonnal condiliorB, neither operation returns any data. 
However, they can raise exceptions. An operation that has 
encoimtered an abnormal condition can communicate this 
fact to its client by raising an exception. When an 0]>eration 
completes, its chent is able to determme whetlier or not the 
operation completed normally or has raised an exception. 

Different types of exceptions can be de filled, each of which 
represents a tlifferent abnomiai condition. The exception 
Unknown Application indicates that the apphcation identified by 
the parameter which^appfication is not known to the enteqnise 
communicator. The exception Already Connected indicates that 
the application that is trying lo connect is already connected 
to the enterprise communicator. The exception NotConnecied 
indicates that an apphcation that is trying to tiiscoiuiect is 
not currently cormected to the enterprise communicator. 

Another important characteristic of the ApplicationConnect 
interface is tliat it inherits the tlefinition specified for the 
interface Composabia, which is described in the next section. 



Multiple Interfaces. Additional ingredient-s of the Concert 
model for components were leveraged from Microsoft's 
Component Object Model (COM), While much of COM de- 
scribes the low-level conventions for performing operation 
invocations on objects, COM also motivates the cortcept of 
representing a component through multiple distinct inter- 
faces. 

fo COM, a client must explicitly ask a component whether it 
supports a particular interface before it can access the hiter- 
face. If the component does indeed support the interface, 
the client can use it. Otlierwise, tlie client must seek another 
inteiface, or try to make do with the interfaces that are sup- 
ported. See "Multiple Interfaces in COM" on page 9L 

Although typically described by Microsoft as a way to evolve 
component functionality through the addition of new inter- 
faces and as a way to simplify perceived problems v^ith ob- 
ject-oriented inheritance, the real strength of multiple inter- 
faces is the ability to model complexity. 

For example, in Concert, components represent significant 
subsets of the overall functionality of an application or sys- 
tem of applications. It would be imwieidy to try to represent 
a component's complete set of capabiUties through a single 
interface- h would be unnatural in many cases to impart 
modularity by organizing these interfaces using inheritance. 

As a simple real- wo rid example of multiple interfaces, con- 
sider the interfaces ihai might represent an employee who is 
also a father and a baseball fan. It is unnatural to model this 
employee's interfaces using an inheritance relationship 
because the interfaces are semantically unrelated. It woitid 
be awkward to define a single employee-specific interface 
because the advantages of developing distinct models for 
the concepts of the employee as father and baseball fan 
become obscured. However, modehng the employee as 
supporting multiple interfaces is essentially how tilings 
w^ork in the real world. 

Concert's adaptation of the COM concept of multiple inter- 
faces is referred to as interface composition. This is be- 
cause a component's functionality is represented by a com- 
position of distinct Inteifaces. The interfaces that the 
component chooses to include in tliis composition can vary 
over time as a function of the component's internal state or 
because its imder lying implementation has changed. 

The interfaces in a Concert interface composition are re- 
ferred to as coynposable interfaces, hi Concert, all compos- 
able interfaces are derived from the base mterfiace Compos able. 



interface Applies tionConnect i CompoBaJDle { 

exception UnknownAppIication {}; 

exception AlreadyConnected {}; 

exception Not Connected {}; 

void connect {in Applicationldentif ier wliicli_ application) 
raises (tlnknownApplicatioHx AlreadyConnected) j 

void disconnect (in Applicationldentif ier which_application) 
raises (UrtknownApplication, NctConnectedj ; 

} i 



Fig. 4. An example of an interface 

defkiitioii. 
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Multiple Interfaces in COM 

In Mcrosoft's Common Object Model ICOM), all ctjmponents implement 
the interface lUriknown. Ttjis interface specifies only a few m^ods 
(method is the COM temi for opsfationl. including the method QueTv- 
Imefface. A client of a component intgrfacetc 

the component lo deierm i ne tf i 1 1 r : i ntsrf ace ■ o 

the cirem, 

Qyerylmerfacs accepts a single input parametet which is used XB indi- 
cate the interface of interest. If the component supports the indicated 
interface, a reference to the interface is returr^ed. This reference can 
then i3e used by the client to access the component vis the interface, ff 
the interlace is not supported, then the special value HULL is returned 

Conceptually, wtltiin a running instance of each COM component, a table 
of the interfaces implemented by the component is maintained. When 
the component instance is initialized, its table is populated with the 
names of all the mterfaces that the component implements Associated 
with each name is a pointer to the code that implements the particular 
interface. 

When Querylnterface is called by a c[ient of the component, the compo- 
nent consults Its table of implemented interfaces, if the interface being 
queried about is implemented, then the reference that is returned con- 
lains data thai essentially points to the implementation of the interface. 
This data enables the component's client to access the interface and 
therefore its underlying implementation. 

In COM, the interfaces that are supported by a component cannot change 
once the component has been initialized. 



The mtcrface Compos able provides fiinctioiiality similar to 
COM's lUnknown:. It supports a method similar to Query Interface 
which enables a component's client to determine whether the 
component implements a particular interface, and if so, to 
oblain a reference to llie interface. For convenience, this 
querying capability is available via any Composable interface. 

In addition, every component implementi* tlie interface Prin- 
cipal, which is also derived from Camposable. In addition to 
providing a way for a component's clients to interrogate a 
component about the interfaces it supports, Principal also 
enables clients to obtain a list of aU of the interfaces that the 
component ctirrentiy implements. For some clients the ability 
to obtain a list of available interfaces is preferred to the 
technique of inierrogating for interfaces one at a time. 

The priinary difference between COM and Concert in terms 
of support for multiple interfaces is that in COM, the con- 
cept only applies to components implemented using COM- 
based lechnologj^. In Concert, tlie concept has been easily 
layered on top of a variety of technologies, including COM, 
CORBA, and even Smalltalk and C++. This enables ConceH 
to apply a powerful architectural notion in a technologically 
flexible majiner. Fig. 5 shows an enterprise cormnunicator's 
intplementation of multiple interface. 

Channels. C"oncert's ohject-oriented component interfiaces 
are primarily intended to be implemented using CORBA- 
based or OljE-based technologies. However, certain compo- 
nent capabilities are better suited for other representations 
that are not necessarily object-oriented or for implementa- 
tions using technologies other than CORBA or OLE. For 



example* backwards eompadbUity with existiiig standards 
or stringent performance constraints might dictate the use 
of other technologies. 

In Concert, a component can have interfaces that su^ not 
object-oriented. These interfaces are referred to as channels. 
Channels generaDy do not offer acc^s to the full set of com- 
ponent capabilities that are represented by a component's 
object-oriented interfaces, but they do provide an architec- 
tural basis for representing alternative communication 
mechanisms. 

For example, an enterprise communicator implements 
TCP/IP channels over which it can send and receive charac- 
ter-formatted HL7 messages. Contemporary^ applications use 
a communicators object-oriented interfaces to send and 
receive messages, but legacy applications can use a conmtu- 
nicator's TCP/IP channels* 

Interface Perspectives. During the early de\'elopmen! of Con- 
cert, most of the empliasis was on the interfaces that repre- 
sented a component s application capabilities. These inter- 
faces support the ability to use the component to construct 
healthcare applications. 

For example, the application capabilities of an enteiprise 
communicator are represented by the following three inter- 
faces: 

• The application connect interface enables an application to 
connect to and disconnect from a communicator. ^Tien 
connected, an application can send or receive HL7 mes- 
sages. WTien disconnected, messages wiW be buffered for 
the apphcation until the next time it connects. 

• The mess^e manager interface enables an application to 
create new empty messages that it can fill with data and 
send and also receive messages that have been sent by 
other applications. 

• The message filter interface enables an application to 
instruct an enterprise conununicator to filter messages 
based upon their data content. Messages that are filtered 
are not delivered to the apphcation. For example, an appli- 
cation might only want to receive messages thai jiertain to 
a particular patient. The enterprise communicaior will send 
to the application only those messages that pertain to the 
indicated patient 

ll was soon recognized that the application construction 
interfaces represented only one perspective for defining a 
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component's inteifaces aiid that therp were other perspec- 
tives that needed to be represented. Specific-ally, wil fun a 
healthcare enterprise, there are at least two other perspec- 
tives that need to be considered: 

• System integration perspective, which is concerned with 
interconnections within and between systems fbr the pur- 
pose of estabUshing mteroperation (typically based lipon 
relevant standards). 

• System management persjDective, which is concerned with 
how sy stents are configured, monitored, admin istered» and 
maintained to preserve desired availability and performance 
levels. 

These perspectives turn out to be extremely important as 
soon as one starts to address basic issues such as how a 
component is starl ed or halted, oj' liow data within a compo- 
nent is accessed by systems and apphcations that arc not 
compon ent-based. 

For example, with an enterprise conmimiicator, there are 
two system integration interfaces. One is an object-oriented 
interface that enables a communicator to send and receive 
binary-encoded HL7 messages. Tlie othei' is a TCP channel 
that enables a comnmnicator to send and receive ASCII- 
encoded HL7 messages. 

For system management purposes, a communicator supports 
seven object-oriented interfaces and o!ie SNMP-based chan- 
nel. The breach h of fimctionalily needed to manage a com- 
mmiicator exceeds llie functioniilit^^ needed to use i( for 
application purposes. Wiiilc this situation was surprising at 
first, it is consistent with the notion that enteqirise-capable 
components must be uiherently manageable. For exaiiii:tle^ il 
woidd not be practical to deploy connniuiicators throughout 
aj^ enterprise if there were no way to monitor their perfor- 
mance ^md intervene from a cent ral location when problems 
occur 

The concept of organizing a component's interfaces in terms 
of application construction, systetn integration, and system 
ntanagement perspectives is one of the cornerstones of Con- 
cert. It is this way of thinking abour components that h^is 
enabled Concert to provide the basLs for components t iiat 
are truly capalile of enteriJrise-wide deployment and use. 

In general, the interfaces tJiat make up these three perspec- 
tives can be thought of as providing an architectural founda- 
tion for component use. Well-defmed interfaces organized in 
a usefitl way lower the obstacles to using components in a 
biack-box manner to construct s>-stems. 

There is, however, a fourth perspective defined in Concert, 
The component customization perspective represents the 
concept that a component may have internal mterfaces that 
are sunilai- to t raditional apphcation progratnniuig interfaces. 
These interfaces can be used to modify a component's ftmc- 
tionahty^ Tlie importajit distinction from an ai-chitectumJ 
perspective is that the customization uiterfaces offer access 
to a components implementation and shoidd not be con- 
fused with the external view offered by the interfaces for 
the other perspectives. 

Hardware analogies for software systems are often a 
sti-etcht but the folio\%ing analogy for a Conceit component 
and its various interface perspectives has proven to be 
effective. A Concert component has sopliistioation tliat is 



roughly analogous to a printed circuit boards such as a 
sound card that one might plug into a personal computer 
Tlie soimd card provides application coiistmction interfaces 
for programs that enable the user to create and control 
sounds. 

The soimd card also provides: 

• System integration interfaces so that the sound card can be 
used in coi\junction with external MlDl-based instruments 
(l.e,, jnstrunients that support the Musical Instrument Digital 
Interface) or with an audio speaker 

• System maj\agement interfaces, often in the fonn of LEDs 
that indicate tlie card's status and DIP switches thai enable 
configuring Uie can! (e.g., setting interrupt vectors or reset- 
tmg the cmd's processor) 

• Customization iriterfaces, such iis sockets for adfiitJonai 
memory chips, whu:ii enable changuig the functionality' 
of tlie card, and tmlike the card's other interfaces, expose 
aspects of the card^s implementation. 

These key component-interface perspectives are iflustrated 
ui Fig. 6. 

The principles for organizing and defining interfaces for 
Concert compt:>nents m terms of these perspectives has 
proven to be productive and straightforward to unplement 
using botli CORBA and OLE automation technolog>^. Tlie 
work to conceive, specif y^ and then hone the definition of 
each interface can be considerable, but the rewards can be 
substantial. 

A well-thought-out and stable set of interface definitions hM 
enabled component design and implementation to proceed 
at a brisk pace. Fujt her, tlie intet^face definitions fonn a rich 
basis for an interesting fonn of reuse referred to as specifi- 
cation reuse. Some of the liehaviors for new tyijes of com- 
ponents can be reused from the set of interfaces and associ- 
ated patterns of use that have already been defmeil 

Tlie use of a conmion and relat ively constrained set of com- 
ponent interfaces across MPG and its pan nei^ will enable 
components to be developed by a single MVQ team, by teams 
in differ ent MPG organizations, and by one or more of MPG's 
pailners. These mterfaces also seive as the basis for open 
MPG systems. The interface definitions are the key points at 
whicii tile systems can be opened. 

Components and the Architecture Reference Model 

The tnily important dimension of C-oncert is not the imder- 
lying component model, whicii is a hybrid of COM and OMA 
concepts, but the actual components that have been con- 
ceived and specified. The first step towards conceiving Con- 
cert components was not the development of the compo- 
nent model, but rather the development of a high-level 
model for healthcare enterprise infonnation systems. 

This model, refened to as the MPG ^irchite<'tnre reference 
model (ARM), identifies the key architectmal ingredients for 
healthcare enterj^rise-capable applications and systems of 
applications/^ Tliese ingredients do not prescribe particular 
system features or teclmologies. Instead, they organize tlie 
architectural content of a software system into ten ma,jor 
gioupings. 

EacJi group describes a broads but nevertheless partitionable, 
subset of an overall system architecture. The stnicture of a 
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system is represented by seven facets, shown on the front of 
the cube shown in Fig. 7. The characteristics of the system 
thar are tratisitive across all of the facets are ilhtstrated as 
three horizontal layers that are stacked behind the facets. 

The technique for graphically depicting these characteristics 
as slices Wtis adapted from work on open distributed pro- 
cessing developed by HP*s former Network Systems Archi- 
tecttire group. 

The aligmiient of the boxes that represent the facets is im- 
jiortant. The facets that represent system featuiTs that are 
most readily perceived by the eiid user are located towards 
the top of the ilhistration, Acjjoining facets have significant 
ijitenelationships and ijtfluences on each otJier, 

Ai^ application in the traditional, intuitive sense is also illus- 
trated as a slice, but this slice only cuts througit the tlu'ee 



iimer facets. In an actxial system^ the softw^are that corre- 
sponds to these facets typically implements application- 
specific beha\iors. 

In contrast, the four outer facets represent the functional 
elements of an appUcation system required to relate appUca- 
tions to each other in a coherent imd consistent manner. 
Iliese outer facets also represent the functional elements of 
an applicarion system needeci to relate the overall system to 
tlie Ileal til caje eiitetprise. 

The final element of the architecture reference model is the 
recogiiirion thaf an application system is designed, developed, 
Implemented, atid sut^ported using tools. The degree to which 
the design, development, mtplementation, and suppoit activi- 
ties are productive is a direct fiuictioii of the dt^gree to wluch 
complementary' tools are employed. 
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Purtiier, for each of these activities, the degree to which 
insightful knowledge of the heaJthcare enten>rise is appJied 
governs the degree to which the resulting application sys- 
tem meets the business needs of the system's supplier and 
satisfies the requirements of the clinical, operational, and 
business customers in the healthcare enterprise. 

Outer Facets (irt Fig. 7). The enterprise communication facet 
represents I he capainlity for a syslem to interchange data 
vtith other systems in tlie em.eri>rise based upon relevant 
healthcare standards. Important elements of this facet are 
the data formats and communication profiles that make up 
the interchjmge standards. 

The information model facet represents the "conceptual 
glue" that is essential for deploying an application system 
within an enterprise. The information model identlHes and 
defines the entities and concepts that are important in the 
domain of the healthcare enteii>rise. The information model 
also helps ensure that these entities, concepts, terminology; 
and clinical processes have a consistent intcrfiretation 
across all parts of an apptjcation system and the enterprise 
as well as between different but related applications. 

The system management facet represents the "operational 
glue" that enables the imiform and consistent management 
of the system. This includes capabilities to: 

• Turn the system on and off 

• Assign passwords for users 

• Install new software revisions 

• Configure the functionality of the software 

• Detect, enunciate, and log faults 

• Int erv^ene to correct faults 

• Actjust performance parameters and resoiu'ce utilization 
levels 

« Provide end-user help-desk functionality. 

The common user enwonment facet defines a uniiying meta- 
phor that governs user interactions with the underlying ap- 
plications. For example, for an electronic medical record 
application system, tlie metaphor might represent patient 
data as sections in a virtual three-ring binder. 

Under the umbrella of the metaphor, the common user envi- 
romnent also defmes the healthcare-specific approach to 
application user interface look and feel (e.g., clinically 
appropriate colors, fonts, terminology for common menu 
selections, etc.), and it provides the highest-level controls, 
which enable the user to navigate to and between applica- 
tions. 

In addition to these specification-oriented elements, the 
common user en\lronment includes capabilities that enable 
the user to log on once to an application system and to 
establish and manage a u^e context ivhich is applicable to 
any of the miderlying applications. The use context can in- 
clude settings that identify the user and describe the user's 
cliuical role, characterize the user^s physical location, and 
indicate the user's natiu-al language preference aixd default 
preferences for application appearance and control settings. 

For exampiej a physician's use context might include the list 
of patients that the physiciaji is responsible for, Tliis list 
resides \\ithiii the implementation of the common user en\i- 
ronment but is accessible to any application in the system. 



As the physician switches between applications, applications 
are provided witii information atjcjut the patients on tlie list 
without requiring the physician to reestablish the list. The 
continuity pro\^ded by the use context enables applications 
to achieve a high degree of coordination and cooperation* 
These qualities benefit the physician by provldhxg a simpler 
and more efficient user interface. 

Inner Facets. The otiter facets of the arcliitectiu'e reference 
model defijie an enterprise environment, witiiin which an 
application participates. An application is described in terms 
of tluee basic application facets, fiepresenting an application 
in this maiuier makes it possible to factor the responsibilities 
of an overall ai^pUcation into jnore granular categories. 

WMe reminiscent of the increasingly popular mulritier clienty 
server systems (in which application processing is distributed 
across a client and a hierarchy of ser\^ers)j the three applica- 
tion facets EU'e not about client^server computing. Instead, 
they are about decomposing application software into three 
distinct sets of responsibilities. This decomposition serves 
as the basis for scalable and extensible appUcation imple- 
mentations that can be deployed on a single computer or on 
a two-tier or N-tier cUent/server network. 

Tlie application user interface facet is responsible for pre- 
senting application data to the user and for providing mech- 
anisms that enable the user to interact with and control the 
application. In this regEu^d, the fundamental role of the user 
interface is to transform computer-based data into tangible 
entities that a user can perceive and manipulate. While this 
is clearly the overall responsibility of an application, tlie 
user interface portion of an application is focused on the 
ergonomic and human-factor aspects of this transformation. 

The models^ services, and agents facet is responsible for: 

• Models 

Validating user inputs before performing significant appli- 
cation data processing tasks and then performing these 
tasks 

Mediating the transformation of application data into con- 
cepts and organizations that facilitate populating a user 
interface with application data 

• Services. Providing application-level facilities that are com- 
mon among but independent of any particular application 

■ Agents* Automating individual user tasks and multiuser 
wor knows. 

The models, services, and agents facet represents a substan- 
tial subset of an application's overall responsibilities. How- 
ever, this facet is notably tievoid of any responsibilities 
peri:aining to the direct interaction with the user or with 
underlying data sources. This facet is neither responsible for 
the 'Tace** put on the application data> nor is it responsible 
for the application data. Instead, this facet serves as the 
bridge in the transformation of data into entities that are 
tangible to the user. 

The application data management facet is responsible for: 

• Storing application data that is important to the user and 
the enterprise 

• Mediating the exchange of application data with other 
systems in the enterprise 
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• Enforcirig the information-model-foased rules that ensure 
the semantic integrity of the application data over time. 

This facet is easily confused with a database. However, a 
datal:>ase is a particular technolog>^, while application data 
tnana^ment represents a set of related responsibilities. For 
example, application data could be stored in a file or come 
from a reaJ-time feed (e.g., a patieiit-connected instnmient) 
as well as from a database. 

Ftirther, one of the key responsibilities of this fac*et is to 
enforce Aindamental data inte^ty rules (often referred to 
as business rules). This includes rules based upon the 
semantics of the data as identified in the information model 
(e.g., the valid set of operations that can be performed on a 
medication order) and enforcement of more basic consis- 
tency rules (e.g., ensuring that updates that affect multiple 
data items are reliably performed on all of the data items). 

Application Svst&'n Characteristics. The final pan of the archi- 
teciure refeiemt' model descrihfS various characteristics of 
an enterprise appUcation system that requires the participa- 
tion of all of the arcliitecture reference model facets. 

F\inctionality is the characterization of an application system 
in terms of user-perceived qualities rhai are indeiJendent of 
aity one application but n^ust be adequaiely supported by all 
ai>plicatirMis. These qualities include performance, tisability, 
and loc aiizability. 

TVust is the characterization of an application system in 
terms of its responsibilities to provide users with a system 
that is secure, reliable, anti available when needed. 

Control is the characterization of an apphcation system in 
terms of its capabilities to be administered, managed, sup- 
ported, and serviced. 

Status and Conclusions 

Conceil was llrst applied in a deployable prototype elec- 
tronic medical rt^tord (HMR) system that was devefopetl by 
HP l^l>oranjri(*s iuul tlie Mayo CUrsic for use at Mayo's Roch- 
ester, Minnesota site. Frotoyi>eji biised upon four types of 
Concert, iipphcation components were developed for this 
project. 

The architecture was subsequently applied by MPG to the 
development of the enterprise comnnmicafjon fnmiework 
(ECFj. An implementation of the entenjrisc communication 
framework has been jiro^ided to the core members of the 
Andover Working Group. 

Por both of these projects CORBA and OLE technologies 
were employed and developmenl proceeded on HP~LDC*and 
Windows'--NT platforms. Substantial practical experience 
was obtained, and several iniportiuit arc hitectui-al refine- 
ments were introduced. Most notal>ly, however, the key con- 
cepts described in this paper were exercised and validated. 

More recently^ Concert has served as the basis for a variety 
of information system product deveiopment activities within 
MPG. The specifications, experiences, and scjme of the soft- 
ware developed for \he EMR and the E("F are being applied. 



It typically takes an objectoriented sofiware developer 
about two weeks to become familiar enough with the archi' 
lecture to begin productive development of Concert-based 
software. Indications are that once this investment is made, 
the speciiications provide a solid, self-consisteni basis for 
j^stem development. 

The next ctiallenge is to further optimize development pro- 
ducli\1t>- through the creation of C oncert component devel- 
opment frameworks. These fi:ameworks would provide code 
skeletons for partially implemented components. Armed 
with an appropriate set of productivity tools, application 
developers would be able to add the necessaiy^ feaaires to 
the skeletons to create fully functional components. Tools 
would also help the developer ""wire" the components to- 
gether to form an application or a system of applications. 
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Object-Oriented Customer Education 

As customers require more trusted advice to solve their business 
problems, the choice of education soliitions has become a strategic 
issue that often precedes and directs the choice of technplogjes. 

byWulf Rehder 



Whether you buy a laptop computer or a lawn mower, you 
expect to learn how hest to use it. For some products it is 
enougli to skim the user's manual. For others you need to 
attend a class, hi the past, pi'oduct training was considered 
an attribute of product support. It came bundled with the 
product and w'as an exi:)ert:ed feature like a power cord or 
the certificate of wananty. This situation has changed. When 
you buy a toy, batteries aie no longer included. Similarly, 
education is no longer automarically included and free with 
the large, enterprise-wide solution purchases customers 
make today, 

in such eiiterpilse projects even laptop computers must be 
designed to work together with many oilier products that 
are often distributed in networks over laige entities or even 
different coimlries. In these en\ironiiients, tiaining on how 
to use a single, standalone product is no longer sufficient. 
Customers now expect more comprehensive senices, rang- 
uig from training in soil skills such as design methodologies 
and project management to proficiency in hands-on imple- 
mentation and online troubleshooting. 

The complexity of solutions, the size of customer projects, 
mid the fact that computer systems aie increttsingly mission- 
critical for most businesses have led to the unbundling of 
product training and to the creation of entirely new product 
lines for professional consulting and education, Trauung has 
clianged from being a product accessory to being a product 
itself. Customer education has grown from under the um- 
brella of product support to becoming a large and profitable 
industty by itself. In this paper, I will focus on the way HP's 



customer education, as part of the HP Professional Senices 
Organization, is meetnig the new challenges of developing 
and delivering to customers a cohesive suite of object- 
oriejned eciucation products. 

Managing the Transition 

It is a tniism that every act of learning is a passage from 
knowing less ro knowing more. Ho W' ever, customer education 
is more ambitious. This miibition shows itself in three w^ays. 
First, it is not enough to fashion data and information into a 
consistent, meaningful body of knowledge. While ui a tram- 
uig class, customers must be led from "knowing what'' to 
"knowing how" ^md lieing able t(j apply the new leiiiiiing to 
their real-life problems. More knowledge must be trans- 
formed into more skills. However, there is a second, comple- 
mentary' aspect to leaiiiing: learning means not only acquir- 
ing more skills, but also acquirmg different skills for new 
tasks in a changing en\lronment 

The successful management of adapting to this change and 
the transition to higher levels of knowledge are the objective 
of customer education for all job roles as showm m Fig. 1. 

Executives must be made aw^are of the risks and benefits 
the change to new^ teclinologies and processes entails for 
the entire company. With this aw arencss they wiH acquire 
the confidence, authority, and credibility to lead their busi- 
ness into previously uncharted terrain. Managers obtain the 
understandhig and expertise to make tlie right technical 
decisions for their teams to be successful. Designers and 
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some phases will b^ tiaversed repeatedly, depending on the 

results obtained so far and on the qiialit>" measures (e.g.. 
completeness* le\"el of detail) applied in the particular 
phase. Therefore* the links of the chain need to be inter- 
preted a*i carles. I'nder the nanie of education life cycle 
services, this simplified framework articulates the fact tlia! 
customer education teaches how to maitage change and 
how to evolve new skills. Customer education has become 
the industry' of facilitaring the transition from Tefinyson s 
"blind and naked i^ioiance* to St, Thomas Aquinas' skiU 
of man "to know what ht^ ouglit to do.'* 




Fig. 2, HP's people, process, aiid tertmol(>g>' apprtiat'lL 

de\'eloi>ers master new i>rofessiona! cnil'ts that help them 
at>ply the lessom> iei^mte<l for the creation of new products. 
Finally, end users realize the concrete benefits of the new^ 
te(*hnoIogies and processes. 

The third dcfming component for contemporary ctistomer 
eiiucation is its coniprehettsKeness. Fig. 2 sp£N:'ities tjie 
three hratu^hcs of a company s assets that need to tj-aixsition 
togellicr in a balanced way: its people, processes, and tech- 
noiogj*. All three are centered on serving common business 
objectives. 

This brief skettii has far-reaching practical ronseqiienres 
for t lie ])ositioning, developnient. and delivery f)f customer 
eclucaljcjii so hit ions. They do nor merely add Mihie to a [>rod- 
uct, but C'leale their own suite of added values. Pig. 3 shows 
this value chain from tlte point where tlte actual interaction 
with tJie customer occurs (for instance, coui^se content re- 
st^ai ch and di^\'ekjpnieiit pliijscs aie left out ). As aiJijropriate. 



Know Thyself 

Before answers about the right path to object technology 
can be given, the right qu€*stions about the stjirting point, the 
path itself, iuid the goals have to be disked. To ev alnate the 
starting point, HP's €:ustomer education services liave devel- 
oped a workshop calletl skills gap iUialysis.^ Fig. 4 shows a 
stej>l)y-step outline of this coui^se. During the luiaJysis, which 
is dcme jomtly with the ciistomerjhe following documents 
are created to serve 4iS the basis for the next transition 
steps: 

' A written siiiiemeni about business needs 

' An invert! on' of current skills 

' A lisi of additii>na) skills to close tlie gap between current 
skills and identified needs 

' Validation of findings and determination of action items. 

A skills gap analysis addresses a company's overall training 
needs and by itself does not result in a dc^tailed traiiiiitg 
plan. To lie niore relevant to the discussioti, we will focus on 
objects. The customised, object-specific version of a skills 
gap analysis is the object-oriented transilion assessment 
workshop.^ Similar to the skills gap analysis, the customer 
and at least two of MP s educational and technical consul- 
tants work through three sets ofciuestions, ^issessing: 
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Qiiestions about Using Objects^ 

What are the goals for your transition to objects? 

• FdI lowing the general evolution of the software industry 

• Benefitting from externa! libranes of reusable components 

• Making the resulting software easfer to mDdily 

• Improving time-to-market for new products 

• Decreasing software development costs, 

What is VDur company's current e^^posure to object technology? 

• Novice level 

• Some people have general knowiedge 

• Some people have used object-like technology, for example by 

programming in Ada 

• The company has successfully completed a small object-oriented project 

• The company has successfully completed a substantial object-ohemed 
project (more than 300 clesses) using a hybrid language like C-h-. GLOS. 
or a purely object-oriented language like Eiffel or Smalltalk, 

What is your company's current software development process? 

• It develops most of its software m-house 

• It outsources its software development 

• It has a recommended software development process (such as 
the waterfall model the spiral model, prototype based, etc.). 

Reference 

1. G. Meyer, Object Success — A Manager's Guide W Object Orientation. Its Impact 
on the Corporation and iis Use for Reengineering tt^e Software Process. Prentice 
Hall, 1935. 



Final Qiiafity Assessment 



Fig. 4. Skills gap anaJysis methodqlogy* 

* The goals of a transition to objects 

' The present skill level aitd object exposure 

' The customer's current software developiiient process* 

A selection of some of tkese questions is enumerated on this 
page, hi the transition ajssessnient worksliop, the skills gap 
analysis culminates in the preparation of a list of the ten 
biggest obstacles for a successful move to objects, jointly 
agreed upon by the customer and Hf^'s consultants. These 
obstacles are different from company to conipany^ but they 
typicaEy faQ into the categories of managenient commitment, 
organized bturiers, fear of change, scarcity of resources, and 
loyalty to legacy systenis. Raiely aie the inhibitors purely 
technical; the switch to new object-oriented tools and 
products is less problematic than overcomuig the "soft" 
issues just mentioned. 

This list of obstacles is tl\e ciocument upon which HP's team 
bases its recommendations for a concrete object adoption 
agenda, mcluding job-specific ciuTituIum patJis. Such a de- 
tailed phm is the fmal outcome of the object-oriented transi- 
tion assessment workshop. 

After the w^orkshop, with the enthusiasm usually quite higli, 
many software development teams want to start their first 
object-oriented development project without delay. At this 
juncture, the HP consultant assiunes the role of a mentor 
and monitoi-s tl\e speed, direction, and resulfi? of the ti^aiisi- 
tion that is now mider way. See "Staiting an Object-Oriented 



Project" on page 100, which simmiarizes a few caveats col- 
lected from many mentoring sessions* 

Four PiOars of Soft Skills 

A glance at the life cycle in Fig. 3 shows that the next phase 
is education plamiing. Based on the sMlls needs, curriculum 
paths are created tliat match specific jobs and roles designed 
to fill the needs. If, for example, system modeling skills are 
missmg, the joint I IP-customer team may defuie Ihe new role 
of a system architect and reconunend a series of courses to 
retrain designers to become aj'cbiiet*tjs. Once the roles are 
itientined, the solutions will be rlesigned and implemented, 
ExiJeriencp has shown that this is not yet tlie place to select 
technologies (such as tools ai^d jmplementarion languages) 
or products (middleware, databases). Instead* t]ie success 
of a transition to object terhnology appears, as our case 
studies with customei^ have shown, to be determined by the 
mastery of four soft skills; softw^are arclutectiue,^* ajiaJ>^is 
and design meUiodology;'* project management/^ and sys- 
tematic reuse." - 

S(}ffware Architeottire. Of the four skills mentioned above, 
archifectij^g a. software system is perhaps the most difficult, 
yet Uie most important and least well-understood skiH. For 
the sake of bre\ity, three of the most important aspects of 
this difficulty are discussed here. First, there arc at least 
four different view^s of a system architecture tliat emphasize 
different but overlapping concerns of high-level system de- 
sign (see Fig, 5). 
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Second, there is the choice of a viable reference architec- 
ture for ail enterprise J which is a blueprint realization of an 
architecture that best fits a gh-en business purpose. 

One of the most successful frameworks for such a reference 
architecture is the so-^^alled three-tier architecture (see 
Fig. 6). Once the tiers with their subsystems tmd intetface 
specifications ha% e been detlned, it is possible to map prod- 
ucts into the framework. For example: 

• Yisual Basic, Fowerl>uilder, or Visual Works for the presenta- 
tion layer 

• C++ to build apphcation programs whose components may 
be running on distributed servers 

• A database or da1:a warehouse hke HP*s Depot/J for the data 
maixagenieni systen\ 

• SoftheiK^h for rhe <levelopnient environnient 

• The Object Request Broker (OHB) softwaie fortlie infra- 
structiu'e logic tlial manages the communication among the 
distributed software components. 

However, it is ad\isable to postpone these technology choices 
imtil after a thorough luialysis and tiesign metlu:>dotogy has 
been applied based on the particular customer requirements 
and ihe aixticipated use castas of ttie iilanned system. See the 
article on page 73 for a definition of tise cases. 

The third difficulty is the lack of a generally accepted nota- 
tion tfiat is Simple to apply and learn and yet rich enough to 
expivss the complex semantics nf objects and their inter- 
actions in the different layers of a software system. HP and 
its partners are working together in conmtittees chartered 
by the Object Maitagement group (OMG) to fonnulale such 
a miified architectural language. 

Analysis and Design. Better knox^it and more mature than 
architect lual uuidels aj'e tlie software anjilysis and design 
uTeliiods. Tiiey i\rv^ often called methodologies, to distingnjsh 
tliem from the methods Ti.e-. the procedures or functions) 
owncfi by objects. A metliotioiogy defines a process that 
allows the ch vision of work into distinct phases, each of 
wiiich has weU<tefmed exit criteria i e.g., fmislung a grapliic 
object uiodel, drawing ah dei>endtnuy diagrams, and agreeing 
on design documents). The goal is to translate ui formal cus- 
tomer requirements into a more foniial structuie tJiai then 
guides the implementation. Besides structured analysis and 
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Fig. 5. Four architecluial views. 



structured design other methodologies inckide ihe waterfaU 
life cycle model of softw^are development and HP Fusion. ^ 

Project Management Once the softw-are architecture has been 
chosen (e.g„ a three-tier reference model) and a methodology' 
team has gone through the phases of system requirements, 
analysis, and design, a project team needs to be chosen to 
implement the design that realizes the architectiure and 
soh^es the business problem. At this point of the transition, 
ttiinkijig about the peculiaiities of object-oriented project 
management becomes important. Because of the inherent 
modularity^ of object-oriented design and ihe ensuing inde- 
pendence and autonomy of subteanis, team building and 
communication nmy become an issue. New rotes and respon- 
sibilities, such as frame worlv arclutect, patteiTi designer, and 
class librarian need to be integrated. Since object-oriented 
design favors the iniplementer who postpones coding and 
(re)uses components as much as possible, performance 
evaluation and reward systems need to be reconsidered, 
Tliis is opposed to the model of rewarding the implementer 
who **hacks'' out the most code. 

Reuse. The foiirth of the recommended soft skills essential 
tor a successful move to object-oriented software develop- 
ment is the incorporation and long-term management of 
systematic reuse. This course combines a discussion of 
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Starting an Object-Oriented Project 



Reading books and magazines will not always guide you through your 
first object-oriented project. A recent issue of a trade magazme had 
24 advertisements for CASE tools. Z6 advertisemerfts for products, and 
23 advertisements for otaject-onented consulting services. Add to this 
the lack of standards, and the process of adopting object technology 
looks truly daunting, However, there are great rewards as long as you 
are ready to follow a well-defined process and make a longer-term 
commitment. 

Vou and your managers may think that the success of the move to 
objects depends on the size of the projects undertaken, the number of 

people involved, and the tools and techniques used. However., in reality 
these factors have little impact on the transition's success. As a rule of 
thumb, the transition of a single software development team to object 
technology takes at least a year 

You will most likely find your organization in one of two stages of adop- 
tion: the investigation phase or an early adoption phase. If in the inves- 
tigation phase, your company is ready to make some investments, but is 
not sure yet if object technology is the right choice. The objective of your 
project, which should be importam but not mtssion-critical. is to provide 
a feasibility proof and show the measurable benefits. If in the early 
adoption pfiase, higher management has probably made a strategic deci- 
sion in favor of object technology, and it is expected that your project will 
make a significant contribution to the business and provide a competitive 
advantage. 



There are several questionnaires that help in assessing where your 
company is in the transition process. Here are some questions that I 
have found useful: 

» Can you formulate a business case for your project that wjII yield a 
measurable, positive net present value INPV) for your organization? 

► What are the investments necessary to fill the skill gaps found in your 
skills gap analysis? 

* What are the specific success factors and possible risks for this project? 

► What object architecture will you pick and why? 

► What outcome of your project shows the feasibility of object technology 
for your organization or your whole company? 

► What will you do with the existing legacy systems? 

* Does it make sense to connect your project to the potential of the intra- 
net and internet? 

The Dbject-oriented transition assessment workshop includes these and 
other questions. They have proven helpful for customers and. despite 
their simplicity, are surprisingly hard to answer. 

Ramesh Balasubramanian 
HP Professional Services 
Organ izah on Ohiepts 
Consultant 



reuse tedinology Cframeworks. patterns, software kits* com- 
ponents, and stiuidai'fls), and tools and processes with orga- 
nizational and managenient Lssues. Tltese latter nonterhnical 
concerns often have the biggest impact on change man age - 
men! and tJie success of the transition to objects.^ In the 
spiiit of hantis-on skill development, the second part of this 
course sjiniulates the steps of systematically building reuse 
into a sol'tw;ire orgatUKalion. Rg. 7 shows t!ie increment^il 
steps from no reuse to systematic reuse through stages thai 
mirror the phases of the Capability Maturity Model (ClVrM), 
which is wideiv used in tlie assessment of software 

Projects versus High Volume 

From the discussion above it should be obvious that the 
approacli to customer education requirements for ttie transi- 
tion to objects is not simply a matter of rerhnologj^ and 
product training. Just as an infonuation teclinolog>' depart- 
ment is much more than a random collection of computers 
and wires, so Ls today's customer education more tiian a 
collection of I rain lug courses. It lias become an industry 
with finely tufK-d [jroduct lines that match the requirements 
of job groups by providing comprehensive training paths, 
from introductory courses to in-deptii specialized skills. 

However, in addition to these task-oriented, individualized 
curriculum paths, increasing emj)hasls is being put on inte- 
grated ciuricula for project teams, departmeiUSt and entire 
organizations. Tliis latter trend has led to two distuict, but 
collaborating branches witiiin tlie customer education busi- 
ness. One branch addresses the difficult, unique ctistom 
software prctject or the transition of, say, a COBOL t)rogram- 
ming team to Smalltalk proficiency. Efforts like these are 



resource-Intensive, of high complexity, and more often than 
not. also low-vohime affairs, (They are tlie human learning 
system equivalents of higlily sophisticated hardw^are and 
software systems, which usually need to be custom-made,) 

For custom-made education solutions to be affordable, such 
higtily complex offerings need to he created in a rep eatable 
and modulai' mamien Examples of custom courses are the 
total innnersion programs, hi these programs, w^hich are 
variously known in the industry as residency programs or 
boot camps, entire te^mis are led thiough a fuur-lo six-week 
customized curriculimi to object-oriented literacy. 

The other, comv>lementar>^ branch of customer education 
addresses the high-volume, low^er-complexity demands. 
These are requests for standard programming hmguage 
courses, Fiuidament^ds of operating systems, system admin- 
istration, networking, and relational datal:)ases — all of which 
figure prominently in most t"WO-or-three-tier business appH- 
catioii (k^velopments. 

These conditions of sening widely diverging interests are 
posing challenges for the development, sales, and delivery 
of educaiion solutions in general and object-oriented educa- 
lion iti particular. The challenges are similar to the ones 
known in traditJoruU product development; 

• F'llmary and secondar>^ research explore tlie maiket 
conditions 

« Investigations define product possibilities 
9 C'uniculum creation involves outsourcing, partnerships, 
and coOabcnations with product divisions and the field 

* After going through the t>pical lab cycles, prere leased 
materiid is valitlated in alpha and beta tests. 
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in paialiel, iiiarketing collateral is being prepared, data 
sheets, sales briefs, and adveilisLng copy are written, cata- 
logs appear worldwide, and indirect and direct sales are 
made. To be suceessftil. a well-managed and diverse team of 
course desigiters, business developers^ solution architects, 
education ad\isors, technologi^ specialists, consultants^ and 
instructors needs to be trained and deployed worldwide. 
Issues of localization, government regulations, copyright 
protection, |)os! release support, updates, and pricing (for 
instance, discotuits, \'olunie buying, specials) are again not 
different from the roUotit of m^or hardw^are and software 
products. 

In light of these considerable complexities, training vendors 
may be templet! to define Uieti' solutions by offering a variety 
of iopi<\s for which tliey have in-house technologj^ expertise 
and then to reshape Oie customei' needs along the lines of 
these topics. The true challenge consists, however, in bas- 
ing edtication solutions on the transition assessment work- 
shops iuid education plans thai have been crafted 
and agreed upon Jointly by the customer and edtication 
consultants. Only siuHi ^^oltrtions have the strategic impact 
of preceding and guiding the choice of implemeniation 
technologies, 

Point Solutions and Product TVaining 

Supporting the kuger picture of education solutions outlineti 
abovt* are several training offerings thai are more specializedt 
ujirrower in scope, or tool and technology related. Here, 
training usually tracks the release, purchase, and installation 
of products. As a consequence, training courses have to be 
uiKlaled in a rhythm following the product uiKlates. TTiis 
es|)ecial]y itichides lartguages convergirvg towards standaids, 
such as ANSI C4'+, different implementations of new kuv 
gtiages, such as Jav.i, iuicl products tiiat bridge evolvijig de 
facto suindards, such as those for distributed computing. 
Rxitmples of llie latter are the Object Rf^^uest Broker (ORB J 
imi}le men tat ions which adhere to the Common Object 
Request Broker Arcbitectitre (CORBA) standards and serve 
as interoperability middleware between CORBA objects arid 
tile emergmg Mitrosoft " OLE atitomation product suite. 
Such software has to be sup[j(jr1e(i iiy several <>pi' rating .sys- 
tems an(J communication protocols. In die case of HP's 0KB 



Fig, 7. Incremental approach to 
reuse and the resulting benefits. 



Plus 2.0 these are the HP-l'X*. Sim So ft Solaris, aitd Micro- 
soft NT platfonns ai\d the HOP (Internet Inter-ORB Proto- 
col platform mdependent) and E>CE CIOP [Common Inter- 
ORB Protoc-ol, HP-UX only) standaids. Using the OOP 
protocol, ORB Plus 2.0 t?^tU interoperate, for instance, with 
Distributed Smalltalk software from ParcPlace-Digiialk. 

From these tyi^ical examples it becomes ob\ious tliat narrow^ 
specialized point solutions and product training can be as 
labor-intensive as the solutions centered around the care for 
people and processes. Since the competitive pressure tor 
training on slmnk-wrapped products is tierce (you can learn 
C++ in coitununity colleges almost free), larger education 
providers ha%'e snrroundeti themselves with satellites of 
smaller, agile patlners, who cati, in liie analogy tised before, 
be compared to suppliers of hardware and software parts. 

Challetiges and New Directions 

One t>f di(^ most exciting everUs in the emergence of object 
technology' is the recent promise of its convergence with 
inteniet technology. To begin with, -Java is a C++-like object- 
oriented language that allows tive objects (for instance, the 
ones creatcfl in its ai>i)lets) to be shared over the net in a 
platform it^dependent way. Java has spal^^aed severiil new 
customer education offerings, including ones on web secu- 
rity and on how to use the web for commercial transactions. 

Furthermore, with the web becoming ntore familiar as a 
medimn for inff>rmation exchange, it is also fast becoming 
a cajididate for alten^atlve training deUvery, complementing 
comimter*4>ased trainitig (CBTj, CD ROMs, and the tradi- 
tional lecttire atKl lab format. Such a depiuiiire from copy- 
righted class material to an essentially open, pubbc fortun 
creates new challenges, but these challenges tue no more 
severe th^ni t be ones faced by softw an^ distribution atid pttb- 
lishing f>n tiie neb This is especially true in tiie high-volume, 
point-solution, and product-training market witere the mate- 
rial is rapicJIy beconting part of a commodity business with 
small differentiating value and practically no proprietary 
lock on content. Instead, as Tim O'Reiny^- suggests (and 
t>ractices for bis own on-line business of compuler books), 
nu jre importat\t than copyright is the development of a brand 
idet^tiiy that re]) resents a consistent, trusted selection of 
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ixigh quality. Tliis is where high-volume customer education 
may be headed in the fuiure. 
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Lisp. He has coauthored severaf articles on these 
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39 Pylse Oximetry Sensors 



Siegfried Ka&tle 

An fiSD manager at HP's 
Patient Monitoring Division, 
i:qfried Kastle is responsi- 
i e for ain/vay gas measure- 
men is and pulse oximetry 
platforms within HP's Medi- 
cal Products Group. Recently 
fie consulted onthedesrgn 
ofthe new family of re- 
usable sensors and was responsible for the j^ensors' 
electrical and optical components and compatibility 
with related instruments. He is professionally mter- 
ested in signal processing and is named as an inven- 
tor in two related patents. He recerved a Diplom 
Ingenieur in electrical engineering in 1982 from the 
University of Stuttgart, Germany After graduating, he 
did system design for satellite transporters at ANT m 
Germany He joined HP's Boblingen Medical Division 
in 13B4. Initially he worked as a development engineer 
on the HP 78834 Series compact patient monitor He 
also investigated the technology for HP Component 
Monitoring System front-end modules and managed 
the de\/elapment of several ASICs. Born in Eberstadt, 
Eaden-WQrtemberg. Germany Siegfried js married 
and has two sons. Music is an important part of his 
life. He sings in a choir, plays trumpet in a brass 
ensemble, and enjoys conducting, His other interests 
include jogging and goinf on education adventures. 

Fried em arm Nailer 

Born in Herrenberg, Ger- 
many, Fnedemann N oiler 
received an MS degree in 
physics in 1975 and a PhD in 
engineering in 1978, both 
fram the University of Stutt- 
gart. Germany After gradu- 
ating, he worked for five 
years at the University's 
Institute of Energetic Systems studying electronic 
beam welding technologies. He is named as an 
inventor in two related patents and has published 
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Siegfried F^Jk 

Siegfried Falk is the indus- 
trial design and mechanical 
engineering manager of the 
HP Patient Monitoring Divi- 
sion and was the program 
■inager for ltieSp02 sen- 
sor project reported in this 
issue. He joined HPs Boblin- 
gen Manufacturing Division 
in 1974 as a materials and process engineer. He went 
on to become the materials and process engineering 
manager of the Computer Division ai Boblingen, and 
in 1967 tie became mechenical engineering manager 
for obs metrical care and patient monitoring at HP's 
Bdblingen Medical Division. Siegfried was horn in 
Untermunkheinn, Baden-Wurttemberg, Germany, He 
rece^ved a Diplom Ingenieur in mechanical engineer- 
ing in 1969 from the Engineering School at Esslingen, 
Germany. He did R&D work at Bizerba and Kissling 
before joining HP, He is professionalfy interested in 
product stewardship. He is married and has one son 
and two daughters. He served a year in the German 
military as a paratrooper His civic activities include 
working in a team to reorganize the museum in the 
city of Calw. fn his free time he enjoys hunting, 
ainning, and traveling. 

Anton Bukta 

Bom in Sokolovac. Croatia, 
Toni Bukta is a mechanical 
design engineer at HP's 
Patient Monitormg Division. 
He was recently a project 
leader for the new SpO^ 
sensors reported in this 
issue and is currentfy work- 
ing on the mechanical de- 
sign of a new chassis for the next-generation patient 
monitor. Previously he did the mechantcal design of 
two recorders for two fetal monitors, the HP Ml 350 A 
and HP Ml 35 1/53 A. He is named as the inventor in 
two patents related to clip and neonatal sensors. He 
joined HP's Bdblingen Medical Division in 1983 after 
working as a too I maker at Daimler Ben? AG. He earned 
a Diplom Ingenieur in mechanical engineering from 
the Engineering School at Esslingen, Germany Toni is 
married and has two children. He enjoys outdoor 
sports r especially tennis and alpine skiing. 
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design. He also worked on software for an earlier 
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of Denver and an MSEE degree from San Jose State 
University in 1967 Before joining HP he worked at 
NASA on aircraft landing systems, and at Ball Aero- 
space on analog and digital circuit destgn and control 
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Tony DfCDien is an R&D pro- 
ject manager at HP's Micro- 
wave Instruments Division 
and IS responsible for the 
fFrmware of the HPCM (high 
aerformance component 
analyzer! products. Previously 
V ne was responsible for the 
^ division's firmware reuse 
project. He earned a BSEE degree in 1980 and an 
MSEE degree in 1981. hoth from Cornell University, 
After graduating he joined HP's Redwood Operation 
in Santa Rosa. Since joining HP he has worked exten- 
sively on the HP 856x spectrum analyser product line 
as a R&D firmware project manager,, project manager, 
and software development engineer. He also helped 
design the power supply for the HP 70001 A main- 
frame. He IS professionally interested m object-ori- 
ented methods, software reuse, and managing in- 
novation He IS a member of the ACM and is a 
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registered electrical engmeer in California. He was 
born in Manila, Philippines, rs married, and has two 
daughters. He serves on the principal's advisor board 
at his daughter's school. Hjs hobbies include cooking 
and playing the piano. 

Jerry J. Uu 

Jerry Liu began his associa- 
rion vi/ith HP in l9S9as3 
sufTifner intern with HP's 
Signal Angfysis Division, 
He joined HP's Micfowave 
Instruments Division 1,MI0) 
after graduating from 
Cornall Untversity, where 
he earned a BSEE degree m 
1991 and an MSBE degree in 1992. While at MID, he 
worked on ttie firmware reuse pro] eel developing the 
firmware framework for instruments described in his 
article. His main responsibilities included the object- 
oriented analysis and design of the framework as 
well as the system architectiire, the thread niodeL 
and the communicarion mechanisms, At the end of 
the project, he transferred to the Integrated Solutions 
Labor atorv at HP Laboratories and is currently re- 
searching measurement system architectures and 
distributed measurement and control systems. Jerry 
is professionally interested in distributed objects 
technology, measurement systems, web technology, 
and real -time systems He was born in Taipei, Tai- 
wan, In his free time he enjoys photography and 
watercolor painting. 
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RabSeliger 

Principal architect at HP's 
Medical Prorfocts Group 
iMPGKRabSeligerleda 
team: from MPG, HP Labors- 
tones, and the Mayo Clinic 
through the architectural 
definition of the Concert 
component-based health- 
care information system. 
He has served as the cochair of the Anrfover Working 
Group, which is a group concerned with daia inter- 
change in healthcare systems, and managed the 
MPG team through the design and development of 
the Enterprise Communication Framework software. 
Previously he led several architectural inlt^^tives to 
increase the interoperabirity between MPG's applica- 
tions and systems. Rob received a BSEE degree from 
Cornell University in 1980. He joined HP and initially 
worked in MPG manufacturing and developed a sys- 
tem that automated the testmg for the signal acquisi- 
tion and conditioning capabilities of MPG's patient 
monitors. He earned an MSEE degree from MIT in 
1305 as an HP resident fellow. After graduation, he 
served as the technical tead for the HP-UX-based 
distributed object platform used for the HP CareVue 
9000 clinical information system. Rob is named as 
a CO inventor for a patent on concurrent updates to 
medical information databases and has published a 
number of articles about using object-oriented tech- 
nology and C+4 to develop healthcare information 
systems He is a member of the Health Level Seven 
standards organiaatiDn and is cochair of a special 
interest group on object brokering technologies, Rob 
is married and has a daughter and a son One of his 
hobbies is renovating his 1 91 7 home to preserve its 
period style and construction He also enjoys doing 
arts and crafts activities with his children and watch- 
ing and playing baseball. 
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Wulf Rehder 

Wulf Rebder is the world- 
wide program manager for 
Internet education at HP's 
Professional Sen/icas Orga- 
nization. Since coming to HP 
in 1986, some of his most 
memorable projects include 
doing simulation and model- 
ing for PA^RISC computers, 
working as a project manager at the Pisa Science 
Center of HPLaboraiories in Italy, and writing test 
algorithms for fieJd-programmahle gate arrays at HP 
Laboratories He Is interested in the process of mak- 
ing complex things simple end has written numerous 
papers in mathematics, theoretical physics, and engi- 
neering. He has also written a humorous book on The 
Germdn Professof siuze the middle ages. Before join- 
ing HP he was a mathematics professor at San Jose 
Stale University and a system performance manager 
at Metaphor Computer Systems. Wulf received a BS 
degree in mathematics and physics from Hamburg 
University in 1969, en MS degree in mathematics and 
statistics from Dortmund University in 1972, and a 
PhD in mathematics from Bed in Technical University 
in 1978. Wulf was born in a small village in northern 
Gennany. He is married and has two children,. He 
enjoys writing essays for hterary magazines, mainly 
on topics that lie in the intersection of technology 
and the humanities, and is the contributing editor for 
the Bloomsbury Review. 
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